is not defined in the Application configuration documentation. While it may just be ignored, at worst it could cause a parsing error (especially when spread over three lines, as you have it).
11/28/2014 11:30:00 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 15-Nov-2014 13:59:24)
11/28/2014 11:30:00 AM | Einstein@Home | Host location: none
11/28/2014 11:30:00 AM | Einstein@Home | General prefs: using your defaults
I just noticed this in the log after I posted my last reply. This would have been the General prefs from BEFORE I added the new GTX 970 cards and updated the project settings. I have updated the project preferences many times now after the new cards and the website reflects the requested 0.33 GPU usage but the project seems to be sending me the old General prefs from 11/15. What do I need to do to make the project update the General prefs?
is not defined in the Application configuration documentation. While it may just be ignored, at worst it could cause a parsing error (especially when spread over three lines, as you have it).
The lines aren't spread over 3 lines as in the post. The lines are all on one line in the XML file. That is just what the browser posted for the paste operation. I'll remove the lines in the app_config file anyway since you said they aren't needed.
Richard, you were correct it seems. The app_config file wasn't being parsed correctly even though it never threw a syntax error in the startup log. I just deleted the 'friendly_name" tag and restarted the client and lo and behold the status lines for E@H tasks now show the correct 0.33 GPU utilization. I don't know where I came up with that tag, I think I must have copied it from someone else's app_config.xml file here in the forum sometime in the past. Weird that it ran fine for the past year with the 0.5 GPU utilization setting I had previously in the file. Thanks so much for helping me figure this issue out.
Richard, you were correct it seems. The app_config file wasn't being parsed correctly even though it never threw a syntax error in the startup log. I just deleted the 'friendly_name" tag and restarted the client and lo and behold the status lines for E@H tasks now show the correct 0.33 GPU utilization. I don't know where I came up with that tag, I think I must have copied it from someone else's app_config.xml file here in the forum sometime in the past. Weird that it ran fine for the past year with the 0.5 GPU utilization setting I had previously in the file. Thanks so much for helping me figure this issue out.
Cheers, Keith
That's why I always refer people back to the original documentation when something weird seems to be happening. Glad it worked this time.
Well, removing the bad tag seems to only have worked on this computer. I removed the same lines from the other cruncher and rebooted and it is still using the old 0.5 GPU resources. Re-read the config files, updated the project preferences again and that cruncher is still stuck on the old setting. Will reset the project and see if that works. [Edit] Some time later. Looks like the project reset did the trick on the other cruncher. Finally am crunching E@H tasks with 0.33 GPU utilization on all computers.
Re-read the config files, updated the project preferences again and that cruncher is still stuck on the old setting. Will reset the project and see if that works. [Edit] Some time later. Looks like the project reset did the trick on the other cruncher. Finally am crunching E@H tasks with 0.33 GPU utilization on all computers.
Keith
In the period it "had not worked" had the host downloaded any new GPU jobs of the type in question? Remember that GPU multiplicity update information travels with successfully downloaded WUs.
And the "stale date" you posted below suggests it was not getting updated from the project source so long as you had the app_config file in force, so I'd guess it needed a new download after it had noticed there was no app_config.
Lastly, aimed not at you but others you may come across this, the reboot may be key, as I've recently encountered a case where clicking the re-read button did not get application of a change I had made, but a full PC reboot did. As you mention rebooting, this would be not an explanation for your case.
Yes, based on the previous suggestions that the preferences wouldn't update unless new work was requested, I did so request 6 new tasks. That still did not fix the problem on that computer. Only the last thing I attempted, the full project reset fixed the problem on that computer. So, clearing the bad tag in the app_config file for the one computer fixed the problem but doing the same exact thing on the other computer didn't. Chalk it up to computer gremlins I guess, just glad its sorted out now.[Edit] Spoke too soon I guess. There is still some strangeness going on the last problem computer. I didn't pay close enough attention to the status line on E@H tasks. I just noticed the 0.33 GPUs portion and soon as I saw that, I assumed I had fixed the problem. Well, it looks like the project is still stuck on the old CPU usage factor of 0.2 and not the 0.6 CPUs for BRP5 tasks that I have set in the app_config.xml file. It is all correct on the other computer, the one that was fixed with no problems once the bad tag was removed in its app_config.xml file.
Finally can put this issue to rest. Even though both app_config.xml files looked identical and had the exact same entries and both always opened correctly as XML files in a browser with no syntax errors, I decided to copy the XML file for the project from the one computer that was reading the CPU and GPU utilization parameters correctly into the recalcitrant computer. When I did the copy, Windows notified me of a file size difference so something was different with the bad XML file it seems. Once I did this I finally had the correct utilization factors for the Einstein project. Something must have not been parsed correctly with the file in the difficult computer. Should have tried this fix sooner instead of multiple resettings of the project. I wouldn't have lost several hours on a BRP5 task that I had to restart from scratch after the resends. So, thanks to all who replied with help.
is not defined in the
)
is not defined in the Application configuration documentation. While it may just be ignored, at worst it could cause a parsing error (especially when spread over three lines, as you have it).
11/28/2014 11:30:00 AM |
)
11/28/2014 11:30:00 AM | Einstein@Home | General prefs: from Einstein@Home (last modified 15-Nov-2014 13:59:24)
11/28/2014 11:30:00 AM | Einstein@Home | Host location: none
11/28/2014 11:30:00 AM | Einstein@Home | General prefs: using your defaults
I just noticed this in the log after I posted my last reply. This would have been the General prefs from BEFORE I added the new GTX 970 cards and updated the project settings. I have updated the project preferences many times now after the new cards and the website reflects the requested 0.33 GPU usage but the project seems to be sending me the old General prefs from 11/15. What do I need to do to make the project update the General prefs?
Keith
RE: is not defined in the
)
The lines aren't spread over 3 lines as in the post. The lines are all on one line in the XML file. That is just what the browser posted for the paste operation. I'll remove the lines in the app_config file anyway since you said they aren't needed.
Thanks, Keith
Richard, you were correct it
)
Richard, you were correct it seems. The app_config file wasn't being parsed correctly even though it never threw a syntax error in the startup log. I just deleted the 'friendly_name" tag and restarted the client and lo and behold the status lines for E@H tasks now show the correct 0.33 GPU utilization. I don't know where I came up with that tag, I think I must have copied it from someone else's app_config.xml file here in the forum sometime in the past. Weird that it ran fine for the past year with the 0.5 GPU utilization setting I had previously in the file. Thanks so much for helping me figure this issue out.
Cheers, Keith
RE: Richard, you were
)
That's why I always refer people back to the original documentation when something weird seems to be happening. Glad it worked this time.
Well, removing the bad tag
)
Well, removing the bad tag seems to only have worked on this computer. I removed the same lines from the other cruncher and rebooted and it is still using the old 0.5 GPU resources. Re-read the config files, updated the project preferences again and that cruncher is still stuck on the old setting. Will reset the project and see if that works. [Edit] Some time later. Looks like the project reset did the trick on the other cruncher. Finally am crunching E@H tasks with 0.33 GPU utilization on all computers.
Keith
RE: Re-read the config
)
In the period it "had not worked" had the host downloaded any new GPU jobs of the type in question? Remember that GPU multiplicity update information travels with successfully downloaded WUs.
And the "stale date" you posted below suggests it was not getting updated from the project source so long as you had the app_config file in force, so I'd guess it needed a new download after it had noticed there was no app_config.
Lastly, aimed not at you but others you may come across this, the reboot may be key, as I've recently encountered a case where clicking the re-read button did not get application of a change I had made, but a full PC reboot did. As you mention rebooting, this would be not an explanation for your case.
Yes, based on the previous
)
Yes, based on the previous suggestions that the preferences wouldn't update unless new work was requested, I did so request 6 new tasks. That still did not fix the problem on that computer. Only the last thing I attempted, the full project reset fixed the problem on that computer. So, clearing the bad tag in the app_config file for the one computer fixed the problem but doing the same exact thing on the other computer didn't. Chalk it up to computer gremlins I guess, just glad its sorted out now.[Edit] Spoke too soon I guess. There is still some strangeness going on the last problem computer. I didn't pay close enough attention to the status line on E@H tasks. I just noticed the 0.33 GPUs portion and soon as I saw that, I assumed I had fixed the problem. Well, it looks like the project is still stuck on the old CPU usage factor of 0.2 and not the 0.6 CPUs for BRP5 tasks that I have set in the app_config.xml file. It is all correct on the other computer, the one that was fixed with no problems once the bad tag was removed in its app_config.xml file.
Keith
Finally can put this issue to
)
Finally can put this issue to rest. Even though both app_config.xml files looked identical and had the exact same entries and both always opened correctly as XML files in a browser with no syntax errors, I decided to copy the XML file for the project from the one computer that was reading the CPU and GPU utilization parameters correctly into the recalcitrant computer. When I did the copy, Windows notified me of a file size difference so something was different with the bad XML file it seems. Once I did this I finally had the correct utilization factors for the Einstein project. Something must have not been parsed correctly with the file in the difficult computer. Should have tried this fix sooner instead of multiple resettings of the project. I wouldn't have lost several hours on a BRP5 task that I had to restart from scratch after the resends. So, thanks to all who replied with help.
Cheers, Keith