I've unhidden my computers and the computer in question is this one: http://einsteinathome.org/host/7269
It is participating in 7 Projects and indeed runs dry on Einstein WU's from time to time. But when it's dry the application remains in the directory and when BOINC decides to download Einstein WU's again, it also downloads a fresh copy of the application. First time i was unsure about it, but meanwhile it has done it three times and the application always has the same timestamp as the WU's downloaded with it.
[…] only the Mac app has a new versionnumber (July) the others are released one month before in June, but also on day 14. ;)
Sorry, I must be going blind … So my Macs had a good reason for their new downloads, but no more light has been shed on the issue at hand.
BTW I'm guessing that the reason my Einstein app is date-stamped at the time it first ran (instead of when it was saved to the HD) may be that its permissions were modified then, in order to allow it to execute.
Any news what the difference between 4.06 and the new 4.12 Mac app?
This update probably addresses an issue in validation between Mac and Windows hosts.
Because of the difference in chip architecture, OS version, compiler, and many other reasons, the results between Mac and Windows computers differ by just a bit. Because of this, a number of good results have been getting marked as invalid, and a WU would be sent to a new host. More can be read about it on this thread, specifically what Bernd says here points to a new app.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
Any news what the difference between 4.06 and the new 4.12 Mac app?
This update probably addresses an issue in validation between Mac and Windows hosts.
Because of the difference in chip architecture, OS version, compiler, and many other reasons, the results between Mac and Windows computers differ by just a bit. Because of this, a number of good results have been getting marked as invalid, and a WU would be sent to a new host. More can be read about it on this thread, specifically what Bernd says here points to a new app.
...
22.07.2006 13:34:40|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.exe
...
Hello? Anyone at home over there?
I think people have run out of ideas on this one. I have 4 machines crunching Einstein at present, and none of them get this effect. Two run BOINC 5.4.9, two still run Trux 5.2.13. No mention of application downloads in the Messages Tabs, the Einstein executables are dated 26 or 27 June 2006. But as far as I know none of these machines ever run out of Einstein work, they always seem to get a new WU in place before the last one has finished. I don't have as much in the Einstein directories either (based on your earlier post), just:
[pre]
05/01/2006 09:10 166 config_S4R2a.cfg
21/06/2006 09:19 139 config_S5R1a.cfg
27/06/2005 23:19 2,745,667 earth_05_09
26/06/2006 21:44 1,077,248 einstein_S5R1_4.02_windows_intelx86.exe
26/06/2006 21:44 3,337,216 einstein_S5R1_4.02_windows_intelx86.pdb
19/07/2006 09:52 126,442 grid_0550_h_T01_S5R1.dat
21/06/2006 09:21 16,209,600 h1_0548.0_S5R1
22/07/2006 09:39 2,443,168 h1_0548.0_S5R1__21_S5R1a_0_0
27/06/2005 23:19 274,843 sun_05_09
[/pre]
where obviously the WU related files change a bit. I wonder if removing the old S4 material, if you still have it, might help with this, maybe it sees an old version there so downloads a new version, and forgets to remove the old version so it happens again and again. Maybe the S4 cleanup needs doing inside BOINC as well as the project folder, 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
... I wonder if removing the old S4 material, if you still have it, might help with this, maybe it sees an old version there so downloads a new version, and forgets to remove the old version so it happens again and again ...
No, that's not it - mine has both Albert 4.37 (S4) and Einstein 4.79 (S3) applications, but the current S5 app is dated 18 June.
Incidentally, if the scheduler could issue instructions to delete the old apps now both previous runs have finished, it could potentially reclaim half a terabyte of users' disk space - 8.63MB x 60,000 plus active hosts.
(...) 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've unhidden my computers
)
I've unhidden my computers and the computer in question is this one:
http://einsteinathome.org/host/7269
It is participating in 7 Projects and indeed runs dry on Einstein WU's from time to time. But when it's dry the application remains in the directory and when BOINC decides to download Einstein WU's again, it also downloads a fresh copy of the application. First time i was unsure about it, but meanwhile it has done it three times and the application always has the same timestamp as the WU's downloaded with it.
This is all, what resides in the Einstein folder:
[pre]
10.12.2005 14:27 239 Config_H_S4hD
10.06.2006 10:38 1.044.480 albert_4.37_windows_intelx86.exe
04.01.2006 19:13 166 config_S4R2a.cfg
28.06.2005 10:30 1.712.128 einstein_4.79_windows_intelx86.exe
28.06.2005 10:29 3.066.880 einstein_4.79_windows_intelx86.pdb
28.06.2005 01:43 2.745.667 earth_05_09
28.06.2005 01:43 274.843 sun_05_09
03.01.2006 19:48 3.230.720 albert_4.37_windows_intelx86.pdb
18.06.2006 15:40 139 config_S5R1a.cfg
23.11.2005 19:43 239 Config_L_S4lD
16.07.2006 18:42 1.077.248 einstein_S5R1_4.02_windows_intelx86.exe
16.07.2006 18:42 3.337.216 einstein_S5R1_4.02_windows_intelx86.pdb
18.06.2006 15:43 16.230.720 h1_0131.5_S5R1
16.07.2006 18:42 20.735 grid_0140_h_T06_S5R1.dat
17.07.2006 12:45 15.184 h1_0131.5_S5R1__548_S5R1a_0_0
17.07.2006 13:45 737.339 h1_0131.5_S5R1__547_S5R1a_0_0
[/pre]
[edit] formatting
Aloha, Uli
OK, thanks for the update
)
OK, thanks for the update Ulrich. Your folder contents are similiar to my locals which don't run the cache dry.
I'll be checking my remote P4 later today, and will post back with what I find.
Alinator
PS: I assume the Athlon hasn't been doing this?
RE: […] only the Mac app
)
Sorry, I must be going blind … So my Macs had a good reason for their new downloads, but no more light has been shed on the issue at hand.
BTW I'm guessing that the reason my Einstein app is date-stamped at the time it first ran (instead of when it was saved to the HD) may be that its permissions were modified then, in order to allow it to execute.
RE: Any news what the
)
This update probably addresses an issue in validation between Mac and Windows hosts.
Because of the difference in chip architecture, OS version, compiler, and many other reasons, the results between Mac and Windows computers differ by just a bit. Because of this, a number of good results have been getting marked as invalid, and a WU would be sent to a new host. More can be read about it on this thread, specifically what Bernd says here points to a new app.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: RE: Any news what the
)
Thanks a lot.
BOINC just did it
)
BOINC just did it again:
21.07.2006 07:03:56|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
21.07.2006 07:03:56|Einstein@Home|Reason: To fetch work
21.07.2006 07:03:56|Einstein@Home|Requesting 17280 seconds of new work
21.07.2006 07:04:01|Einstein@Home|Scheduler request succeeded
21.07.2006 07:04:03|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.exe
21.07.2006 07:04:03|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.pdb
21.07.2006 07:04:13|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.exe
21.07.2006 07:04:13|Einstein@Home|Throughput 116421 bytes/sec
21.07.2006 07:04:13|Einstein@Home|Started download of file grid_0140_h_T05_S5R1.dat
21.07.2006 07:04:15|Einstein@Home|Finished download of file grid_0140_h_T05_S5R1.dat
21.07.2006 07:04:15|Einstein@Home|Throughput 45381 bytes/sec
21.07.2006 07:04:23|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.pdb
21.07.2006 07:04:23|Einstein@Home|Throughput 179352 bytes/sec
21.07.2006 07:04:24||Rescheduling CPU: files downloaded
21.07.2006 07:04:24||Rescheduling CPU: files downloaded
21.07.2006 07:04:24|SETI@home Beta Test|Pausing task 02ap05aa.26317.306.548552.3.194_2 (left in memory)
21.07.2006 07:04:24|Einstein@Home|Starting task h1_0131.5_S5R1__443_S5R1a_1 using einstein_S5R1 version 402
21.07.2006 07:04:32||Suspending network activity - user request
Still no further info on this behaviour?
Aloha, Uli
Here we go
)
Here we go again:
22.07.2006 13:34:33|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
22.07.2006 13:34:33|Einstein@Home|Reason: To fetch work
22.07.2006 13:34:33|Einstein@Home|Requesting 17280 seconds of new work
22.07.2006 13:34:38|Einstein@Home|Scheduler request succeeded
22.07.2006 13:34:40|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.exe
22.07.2006 13:34:40|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.pdb
22.07.2006 13:34:51|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.exe
22.07.2006 13:34:51|Einstein@Home|Throughput 116295 bytes/sec
22.07.2006 13:34:51|Einstein@Home|Started download of file grid_0140_h_T05_S5R1.dat
22.07.2006 13:34:52|Einstein@Home|Finished download of file grid_0140_h_T05_S5R1.dat
22.07.2006 13:34:52|Einstein@Home|Throughput 46512 bytes/sec
22.07.2006 13:35:00|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.pdb
22.07.2006 13:35:00|Einstein@Home|Throughput 179256 bytes/sec
Hello? Anyone at home over there?
Aloha, Uli
RE: Here we go
)
I think people have run out of ideas on this one. I have 4 machines crunching Einstein at present, and none of them get this effect. Two run BOINC 5.4.9, two still run Trux 5.2.13. No mention of application downloads in the Messages Tabs, the Einstein executables are dated 26 or 27 June 2006. But as far as I know none of these machines ever run out of Einstein work, they always seem to get a new WU in place before the last one has finished. I don't have as much in the Einstein directories either (based on your earlier post), just:
[pre]
05/01/2006 09:10 166 config_S4R2a.cfg
21/06/2006 09:19 139 config_S5R1a.cfg
27/06/2005 23:19 2,745,667 earth_05_09
26/06/2006 21:44 1,077,248 einstein_S5R1_4.02_windows_intelx86.exe
26/06/2006 21:44 3,337,216 einstein_S5R1_4.02_windows_intelx86.pdb
19/07/2006 09:52 126,442 grid_0550_h_T01_S5R1.dat
21/06/2006 09:21 16,209,600 h1_0548.0_S5R1
22/07/2006 09:39 2,443,168 h1_0548.0_S5R1__21_S5R1a_0_0
27/06/2005 23:19 274,843 sun_05_09
[/pre]
where obviously the WU related files change a bit. I wonder if removing the old S4 material, if you still have it, might help with this, maybe it sees an old version there so downloads a new version, and forgets to remove the old version so it happens again and again. Maybe the S4 cleanup needs doing inside BOINC as well as the project folder, 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
RE: ... I wonder if
)
No, that's not it - mine has both Albert 4.37 (S4) and Einstein 4.79 (S3) applications, but the current S5 app is dated 18 June.
Incidentally, if the scheduler could issue instructions to delete the old apps now both previous runs have finished, it could potentially reclaim half a terabyte of users' disk space - 8.63MB x 60,000 plus active hosts.
RE: (...) so if it was me,
)
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* ;)
Aloha, Uli