Something else "strange . . ." - I checked the Einstein folder for my other host (which reported its last WU from cache yesterday) and there isn't an Einstein app in the folder anymore.
Edit: This host is currently in EDF mode because it has too much work from SZTAKI.
Edit2: After browsing through the scheduler logs, it appears this is happening a lot to Windows hosts. As I said earlier, I bet they are do this to "purge" any remaining apps with Akos patches.
This host returned to round-robin mode today and promptly downloaded einstein_S5R1_4.02_windows_intelx86.exe along with 4 new WU's. I looked at the scheduler log (to confirm my download) and again, happened to notice that the application was being downloaded to several other (Windows) hosts. This made me wonder: Has anyone seen this behavior on any other platform?
(...) so if it was me, I would run the WU's out completely, and do a detach and reattach to the project. If you have done that I regret I've got no other ideas. Good luck. Mike
Yes thanks, i'll try that when the cache runs dry.
I've avoided that until now, cause i liked my low host ID (7269) so much, *sigh* ;)
I recently detached/reattached one of my hosts to Predictor@Home fully expecting to have to merge the newly created host ID into the old one. However, I was surprised to discover that the original host ID was still in my computer list and showed the new work units that it had downloaded. It was as if the detach had never happened. I wonder if this a feature that was added into the current version of the BOINC server software.
Does anyone know if Einstein preserves host IDs after a detach also? Maybe Uli won't have to give up that low host ID after all...
After a project reset ( preserving the host ID ;) ) it magically stopped downloading the application again and again:
31.07.2006 00:20:25|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
31.07.2006 00:20:25|Einstein@Home|Reason: To fetch work
31.07.2006 00:20:25|Einstein@Home|Requesting 129600 seconds of new work
31.07.2006 00:20:40|Einstein@Home|Scheduler request succeeded
31.07.2006 00:20:42|Einstein@Home|Started download of file grid_0140_h_T02_S5R1.dat
31.07.2006 00:20:44|Einstein@Home|Finished download of file grid_0140_h_T02_S5R1.dat
31.07.2006 00:20:44|Einstein@Home|Throughput 18318 bytes/sec
31.07.2006 00:20:45|Einstein@Home|Starting task h1_0131.5_S5R1__191_S5R1a_0 using einstein_S5R1 version 402
The "download" phenomenon is still occurring on both my computers. I intend to do a reset (as Uli did) to see if it makes any difference for me. But first, I thought I would report these observations: My current Einstein resource share is such that my computers run through whatever WU's are in cache (and report the results) but wait for a day or so before requesting new work from the project. When this happens, the Einstein application is deleted from the Einstein Project folder at the time the last WU result is reported to the server. (I watched this happen as my last WU from HOST#382766 was first uploaded and then reported.) Then, when new work is requested, the Einstein application is downloaded again.
As it happens, some of my other BOINC projects are also periodically running through their WU's in cache and waiting a day or so to request new work. But Einstein is the only project which is deleting its application and downloading it again. And (as I observed in my last post) this application "download" phenomenon seems to be happening fairly regularly on Einstein "Windows" hosts - but, apparently, it is not happening on other platforms.
Below is a copy of the last server log entries for my HOST#382766. (It shows the entries during the time when the application was last deleted - but, the log does not explicitly indicate the deletion.):
RE: Something else "strange
)
This host returned to round-robin mode today and promptly downloaded einstein_S5R1_4.02_windows_intelx86.exe along with 4 new WU's. I looked at the scheduler log (to confirm my download) and again, happened to notice that the application was being downloaded to several other (Windows) hosts. This made me wonder: Has anyone seen this behavior on any other platform?
RE: RE: (...) so if it
)
I recently detached/reattached one of my hosts to Predictor@Home fully expecting to have to merge the newly created host ID into the old one. However, I was surprised to discover that the original host ID was still in my computer list and showed the new work units that it had downloaded. It was as if the detach had never happened. I wonder if this a feature that was added into the current version of the BOINC server software.
Does anyone know if Einstein preserves host IDs after a detach also? Maybe Uli won't have to give up that low host ID after all...
Regards,
-- Tony
After a project reset (
)
After a project reset ( preserving the host ID ;) ) it magically stopped downloading the application again and again:
31.07.2006 00:20:25|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
31.07.2006 00:20:25|Einstein@Home|Reason: To fetch work
31.07.2006 00:20:25|Einstein@Home|Requesting 129600 seconds of new work
31.07.2006 00:20:40|Einstein@Home|Scheduler request succeeded
31.07.2006 00:20:42|Einstein@Home|Started download of file grid_0140_h_T02_S5R1.dat
31.07.2006 00:20:44|Einstein@Home|Finished download of file grid_0140_h_T02_S5R1.dat
31.07.2006 00:20:44|Einstein@Home|Throughput 18318 bytes/sec
31.07.2006 00:20:45|Einstein@Home|Starting task h1_0131.5_S5R1__191_S5R1a_0 using einstein_S5R1 version 402
Thanks to all for trying to help. :D
Aloha, Uli
The "download" phenomenon is
)
The "download" phenomenon is still occurring on both my computers. I intend to do a reset (as Uli did) to see if it makes any difference for me. But first, I thought I would report these observations: My current Einstein resource share is such that my computers run through whatever WU's are in cache (and report the results) but wait for a day or so before requesting new work from the project. When this happens, the Einstein application is deleted from the Einstein Project folder at the time the last WU result is reported to the server. (I watched this happen as my last WU from HOST#382766 was first uploaded and then reported.) Then, when new work is requested, the Einstein application is downloaded again.
As it happens, some of my other BOINC projects are also periodically running through their WU's in cache and waiting a day or so to request new work. But Einstein is the only project which is deleting its application and downloading it again. And (as I observed in my last post) this application "download" phenomenon seems to be happening fairly regularly on Einstein "Windows" hosts - but, apparently, it is not happening on other platforms.
Below is a copy of the last server log entries for my HOST#382766. (It shows the entries during the time when the application was last deleted - but, the log does not explicitly indicate the deletion.):
HTTP_ACCEPT=*/* HTTP_USER_AGENT=BOINC client (windows_intelx86 5.4.9) 2006-08-02 16:16:20.4589 [PID=27702] [debug ] CONTENT_LENGTH=6001 2006-08-02 16:16:20.5315 [PID=27702] [normal ] Handling request: host 382766, platform windows_intelx86, version 5.4.9, RSF 0.080000 2006-08-02 16:16:20.5316 [PID=27702] [normal ] OS version Microsoft Windows XP Professional Edition, Service Pack 2, (05.01.2600.00) 2006-08-02 16:16:20.5374 [PID=27702] [debug ] Request [HOST#382766] Database [HOST#382766] Request [RPC#4059] Database [RPC#4058] 2006-08-02 16:16:20.5383 [PID=27702] [normal ] Processing request [HOST#382766] [RPC#4059] core client version 5.4.9 2006-08-02 16:16:20.5412 [PID=27702] [debug ] [HOST#382766] Resetting nresults_today 2006-08-02 16:16:20.5426 [PID=27702] [normal ] [HOST#382766] [RESULT#38074165 h1_1272.5_S5R1__2651_S5R1a_1] got result (DB: server_state=4 outcome=0 client_state=0 validate_state=0 delete_state=0) 2006-08-02 16:16:20.5427 [PID=27702] [debug ] cpu 42488.906047 cpcs 0.002658, cc 177.733796 2006-08-02 16:16:20.5427 [PID=27702] [debug ] [RESULT#38074165 h1_1272.5_S5R1__2651_S5R1a_1]: setting outcome SUCCESS 2006-08-02 16:16:20.5583 [PID=27702] [normal ] sending delay request 60.000000