BOINC always downloads new einstein_S5R1_4.02_windows_intelx86.exe?
16 Jul 2006 16:45:28 UTC
Topic 191575
(moderation:
Hi everyone!
Every time i get new WU's from einstein BOINC also downloads a fresh copy of einstein_S5R1_4.02_windows_intelx86.exe and einstein_S5R1_4.02_windows_intelx86.pdb.
Why does it do that? I think it's a waste of bandwidth.
Any suggestions welcome.
I'm puzzled :?
[edit] BOINC version is 5.4.9
16.07.2006 18:41:48|Einstein@Home|Scheduler request succeeded
16.07.2006 18:41:50|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.exe
16.07.2006 18:41:50|Einstein@Home|Started download of file einstein_S5R1_4.02_windows_intelx86.pdb
16.07.2006 18:42:00|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.exe
16.07.2006 18:42:00|Einstein@Home|Throughput 115920 bytes/sec
16.07.2006 18:42:00|Einstein@Home|Started download of file grid_0140_h_T06_S5R1.dat
16.07.2006 18:42:01|Einstein@Home|Finished download of file grid_0140_h_T06_S5R1.dat
16.07.2006 18:42:01|Einstein@Home|Throughput 39798 bytes/sec
16.07.2006 18:42:09|Einstein@Home|Finished download of file einstein_S5R1_4.02_windows_intelx86.pdb
16.07.2006 18:42:09|Einstein@Home|Throughput 178776 bytes/sec
Aloha, Uli
BOINC always downloads new einstein_S5R1_4.02_windows_intelx86.e
)
Just checked my Einstein folder and confirmed that Uli is right. My Einstein app et al is timestamped with the same time of my last WU download. Maybe they are doing this to ensure that nobody is using Akos' patches anymore.
The scheduler log confirms
)
The scheduler log confirms this.
Strange...
Michael
Team Linux Users Everywhere
RE: The scheduler log
)
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.
Just checked my local hosts
)
Just checked my local hosts and timestamps/log entries aren't showing this. They both contacted for new work today.
For the remote ones I'll have to try and catch it between the work request and the result report to see if they get an app DL in the scheduler logs (or wait until I get a chance to take a look at them).
Very curious.
Alinator
I seem to recall this
)
I seem to recall this happening in the past with Predictor@Home when the host ran out of work for a particular science app. When the host received new work, the science app was re-downloaded. That said, none of my machines have exhibited this behavior recently even though frequent bouts of EDF have caused them to run dry of some project or another (including Predictor). I wonder if this was a bug that was fixed in the transition from 4.x to 5.x BOINC.
Regards,
-- Tony
[Edit] I just re-read Uli's post and realised that he is using BOINC 5.4.9. So much for the "old bug" theory...
Just caught one of the remote
)
Just caught one of the remote hosts after a new work request:
REQUEST_METHOD=POST CONTENT_TYPE=application/x-www-form-urlencoded HTTP_ACCEPT=*/* HTTP_USER_AGENT=BOINC client (windows_intelx86 5.3.12)
2006-07-17 14:40:27.8211 [PID=2095 ] [debug ] CONTENT_LENGTH=6140
2006-07-17 14:40:27.9294 [PID=2095 ] [normal ] Handling request: host 656342, platform windows_intelx86, version 5.3.12, RSF 0.200000
2006-07-17 14:40:27.9294 [PID=2095 ] [normal ] OS version Microsoft Windows XP Home Edition, Service Pack 2, (05.01.2600.00)
2006-07-17 14:40:27.9739 [PID=2095 ] [debug ] [HOST#656342] Sending app_version einstein_S5R1 windows_intelx86 402
2006-07-17 14:40:27.9743 [PID=2095 ] [debug ] [HOST#656342] Already has file h1_0180.0_S5R1
2006-07-17 14:40:27.9743 [PID=2095 ] [debug ] [HOST#656342] reducing disk needed for WU by 16230720 bytes (length of h1_0180.0_S5R1)
2006-07-17 14:40:27.9749 [PID=2095 ] [debug ] est cpu dur 12636.382152; running_frac 0.960707; rsf 0.200000; est 6563.069178
2006-07-17 14:40:27.9749 [PID=2095 ] [normal ] [HOST#656342] Sending [RESULT#37013174 h1_0180.0_S5R1__2982_S5R1a_1] (fills 6563.07 seconds)
2006-07-17 14:40:27.9869 [PID=2095 ] [normal ] [HOST#656342] Sent 1 results [scheduler ran 0.166615 seconds]
2006-07-17 14:40:27.9877 [PID=2095 ] [normal ] sending delay request 60.000000
The debug message seems to indicate it sent the app to the host, but I'll have to get over to it's location and check the file timestamp to see if it really was sent to it.
Alinator
I don't think it is really
)
I don't think it is really sending the app each time, just ackowledging that it is needed.
It may be if the host runs completely out of work for that app. In that case BOINC may delete the app to clean up the disk and then redownload it the next time. This is basically what was happening with PP@H back when they reverted to an earlier app. The client would delete the app after each task since it had a later version on hand. Then it would have to download it again for the next task since that task would not use the later version.
Note to projects: Never revert to an older app, if the new one is broken recompile the old version and give it a new number.
BOINC WIKI
BOINCing since 2002/12/8
Thanks for the memory jog
)
Thanks for the memory jog about the problem with PAH, I just couldn't quite put my finger on it to save my life!
In my case, I cleared out the EAH folders when S5 came out to remove all traces of S4 and the AKOS S4 apps, and have let BOINC handle all app related activities since. So I don't think "retrograde versioning" would be an issue for me.
As I said before, for my local machines the timestamp for the app dates back to the intial DL when they started on S5. For the others I'm going to make a trip over there to take a look at the local logs and file timestamps. I'm expecting to see the same thing, but can't say for sure at this point. ;-)
One factor here is my P4 host, which was the one I just caught in the scheduler logs, does run the cache dry from time to time due to it's preferences (EAH has a lower resource share), so it would be the one to show this effect if your hypothesis is correct.
In any event, Ulrich has his hidden, so we have to wait until he pops back in to get more information about how his fit in with theory. :-)
Alinator
RE: As I said before, for
)
On this Mac (G4/400, OS 10.3.9), my “einstein_S5R1_4.12_powerpc-apple-darwin� app file is dated to when it first ran (yesterday morning), not to when it was downloaded (the day before), according to my BOINC message logs. (Note that the Applications page shows that the “Faster� apps for all platforms except Solaris were updated on Friday.)
BTW, this Mac’s E@h project folder still contains the old apps “albert_4.67_powerpc-apple-darwin� (“Improved� beta, from mid-June) and “einstein_4.82_powerpc-apple-darwin� (the original, from mid-December), so I doubt they routinely get cleaned out unless they’re directly superseded. BOINC was first installed here at v5.2.13 (Menubar), recently updated to v5.4.9.
RE: (Note that the
)
No, only the Mac app has a new versionnumber (July) the others are released one month before in June, but also on day 14. ;)
@staff: Any news what the difference between 4.06 and the new 4.12 Mac app?