2005-12-11 08:26:48 [climateprediction.net] Deferring computation for result 1j8v_100092335_1
2005-12-11 08:26:48 [Einstein@Home] Resuming computation for result w1_0833.5__0833.5_0.1_T05_S4hD_2 using einstein version 479
2005-12-11 08:26:48 [---] Using earliest-deadline-first scheduling because computer is overcommitted.
These are the key lines to your problem, the BOINC manager thinks your computer is overcommitted, and in danger of missing deadlines. Thus, it is doing work which has the earliest deadlines first in order to minimize the damage. The plot thickens, however, because you aren't in danger of missing any Einstein deadlines. Your computer also has the strange habit of downloading four or more work units at a time, which shouldn't happen unless your 'connect to network' time is large (which has already been established to be untrue). There are two questions which may help:
1) If you go the work tab, what do you see? Does it look to you like you will miss a deadline?
2)If you go to stdoutdae.txt, and scroll down to 11 Dec 2005 0:16:02 UTC (keep in mind you must convert to your local time zone, and the times may be a bit different due to clock differences), what do you see? For this, you are looking for lines of the form:
with the obvious difference in the time stamp. This will give the download message at the time of your latest download from EAH. 10-20 lines starting with the lines of this form may shed light on why you download 4-5 units at once.
EDIT: it occurred to me that I could check #2 myself. According to the scheduler logs, at 00:16 UTC on 12/11/2005 you requested 136438.652935 seconds of work. That's nearly 2 days worth, assuming EAH is run exclusively (the expected behavior if it expects to connect every 7 days). Why that is happening, and how to fix it, I'm not sure. The only thing I can suggest would be to hit the update button after selecting EAH, which should cause BOINC to re-check your preferences (among other things), although it should do this on its own.
One thing that may be going on is the queue may be set to '.1' instead of '0.1'. It seems like if you omit the leading zero strange things sometimes happen.
The image he showed was clearly 0.1 days but that behaviour is interesting so thanks for the info.
nfortino is right on the money with his comments and I fully agree. There is no way it should be trying to download multiple EAH results if the value is 0.1
Here's a thought to consider. What if the change from 0.1 to 7 days was done at a time when Seti was communicating so that both Seti and EAH became aware of that change. What then if the 7 days was changed back to 0.1 days on the Seti website but before the value was communicated to other projects, Seti started dropping all "Update" requests from the client? When Seti was running down the large cache, unless results were being uploaded and reported successfully, would the change in pref make it back to the local client and then be passed on to the EAH servers?
Jason showed us one page where the value was clearly 0.1 days. Could EAH have been still 7 dsys at the time when all the extra work was downloaded. Somehow it must have been.
I guess it's a moot point now. With Seti hopefully suspended and with EAH showing 0.1 days, the scheduler should drop out of EDF fairly quickly and resume normal round-robin scheduling.
well this morning when i checked it seems to have been sharing betweeen einstien and climate prediction resoanable well so not sure what has happened in meantime but it all seems to have been sorted out.
thank you all for your help on this problem.
i think from this topic we can all learn something
NEVER SET IT TO 7 DAYS TO GET WORK THEN SWITCH BACK TO 0.1
WELL I THINK THAT WAS CASE ABOUT THE OVERLOADING ANYWAY BUT IM JUST THE AMUATER IN ALL THIS
RE: 2005-12-11 08:26:48
)
These are the key lines to your problem, the BOINC manager thinks your computer is overcommitted, and in danger of missing deadlines. Thus, it is doing work which has the earliest deadlines first in order to minimize the damage. The plot thickens, however, because you aren't in danger of missing any Einstein deadlines. Your computer also has the strange habit of downloading four or more work units at a time, which shouldn't happen unless your 'connect to network' time is large (which has already been established to be untrue). There are two questions which may help:
1) If you go the work tab, what do you see? Does it look to you like you will miss a deadline?
2)If you go to stdoutdae.txt, and scroll down to 11 Dec 2005 0:16:02 UTC (keep in mind you must convert to your local time zone, and the times may be a bit different due to clock differences), what do you see? For this, you are looking for lines of the form:
2005-12-08 04:02:27 [Einstein@Home] Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
2005-12-08 04:02:27 [Einstein@Home] Requesting 1 seconds of work, returning 0 results
2005-12-08 04:02:28 [Einstein@Home] Scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi succeeded
with the obvious difference in the time stamp. This will give the download message at the time of your latest download from EAH. 10-20 lines starting with the lines of this form may shed light on why you download 4-5 units at once.
EDIT: it occurred to me that I could check #2 myself. According to the scheduler logs, at 00:16 UTC on 12/11/2005 you requested 136438.652935 seconds of work. That's nearly 2 days worth, assuming EAH is run exclusively (the expected behavior if it expects to connect every 7 days). Why that is happening, and how to fix it, I'm not sure. The only thing I can suggest would be to hit the update button after selecting EAH, which should cause BOINC to re-check your preferences (among other things), although it should do this on its own.
One thing that may be going
)
One thing that may be going on is the queue may be set to '.1' instead of '0.1'. It seems like if you omit the leading zero strange things sometimes happen.
BOINC WIKI
BOINCing since 2002/12/8
The image he showed was
)
The image he showed was clearly 0.1 days but that behaviour is interesting so thanks for the info.
nfortino is right on the money with his comments and I fully agree. There is no way it should be trying to download multiple EAH results if the value is 0.1
Here's a thought to consider. What if the change from 0.1 to 7 days was done at a time when Seti was communicating so that both Seti and EAH became aware of that change. What then if the 7 days was changed back to 0.1 days on the Seti website but before the value was communicated to other projects, Seti started dropping all "Update" requests from the client? When Seti was running down the large cache, unless results were being uploaded and reported successfully, would the change in pref make it back to the local client and then be passed on to the EAH servers?
Jason showed us one page where the value was clearly 0.1 days. Could EAH have been still 7 dsys at the time when all the extra work was downloaded. Somehow it must have been.
I guess it's a moot point now. With Seti hopefully suspended and with EAH showing 0.1 days, the scheduler should drop out of EDF fairly quickly and resume normal round-robin scheduling.
Cheers,
Gary.
Hi all well this morning
)
Hi all
well this morning when i checked it seems to have been sharing betweeen einstien and climate prediction resoanable well so not sure what has happened in meantime but it all seems to have been sorted out.
thank you all for your help on this problem.
i think from this topic we can all learn something
NEVER SET IT TO 7 DAYS TO GET WORK THEN SWITCH BACK TO 0.1
WELL I THINK THAT WAS CASE ABOUT THE OVERLOADING ANYWAY BUT IM JUST THE AMUATER IN ALL THIS
Again thank you all for help