No work sent, won't finish in time
3 Mar 2009 1:21:08 UTC
Topic 194214
(moderation:
All of the sudden I am getting these messages:
3/2/2009 1:17:09 AM|Einstein@Home|Scheduler request completed: got 0 new tasks
3/2/2009 1:17:09 AM|Einstein@Home|Message from server: No work sent
3/2/2009 1:17:09 AM|Einstein@Home|Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 8.3% of that
3/2/2009 1:18:09 AM|Einstein@Home|Sending scheduler request: To fetch work. Requesting 6236 seconds of work, reporting 0 completed tasks
3/2/2009 1:18:14 AM|Einstein@Home|Scheduler request completed: got 0 new tasks
3/2/2009 1:18:14 AM|Einstein@Home|Message from server: No work sent
3/2/2009 1:18:14 AM|Einstein@Home|Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 8.3% of that
3/2/2009 1:19:14 AM|Einstein@Home|Sending scheduler request: To fetch work. Requesting 9297 seconds of work, reporting 0 completed tasks
3/2/2009 1:19:19 AM|Einstein@Home|Scheduler request completed: got 0 new tasks
3/2/2009 1:19:19 AM|Einstein@Home|Message from server: No work sent
3/2/2009 1:19:19 AM|Einstein@Home|Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 8.3% of that
3/2/2009 1:20:19 AM|Einstein@Home|Sending scheduler request: To fetch work. Requesting 12147 seconds of work, reporting 0 completed tasks
3/2/2009 1:20:24 AM|Einstein@Home|Scheduler request completed: got 0 new tasks
3/2/2009 1:20:24 AM|Einstein@Home|Message from server: No work sent
3/2/2009 1:20:24 AM|Einstein@Home|Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 8.3% of that
BOINC and Einstein @ home have been working very well for many months... this has been happening over the past week or so. I don't get it.
I did do an uninstall and reinstall, but the messages are back.
Any advice?
Thanks much!
No work sent, won't finish in time
)
It looks very much like your CPU efficiency is now only 0.083 for some reason. In other words around 92% of your CPU cycles are being used for something else and only 8% are available to BOINC. If your machine isn't doing some other very compute intensive work, you have to ask yourself why BOINC thinks it is. Obviously this situation has been gradually getting worse for some time and now BOINC has determined that there will not be enough future CPU cycles available to it to justify the downloading of new work.
You can get a quick and dirty fix to the current situation by stopping BOINC and browsing your state file (client_state.xml) with a text editor like notepad to see the value of cpu_efficiency. If it is indeed of the order of 0.083xxx you can edit it to read 0.999999, save the file and then restart BOINC. This would immediately allow you to download a full cache of work but it wouldn't solve whatever caused this situation to arise in the first place. If your CPU efficiency isn't the problem, have a look at all the parameters in your state file under the tag and let us know what they are.
What other stuff runs on your machine? Any chance you have picked up some sort of malware?
The problem is not of BOINC's making so doing that is probably just a waste of time. You need to identify why BOINC isn't getting a normal share of your CPU cycles and fix that. With my own machines, I have seen some examples of drastic reduction in CPU efficiency caused by the science app "spinning its wheels". In other words, the task appears to be running but there is no increment in CPU time. This appears to be caused by too high ambient temperature. Cooling the environment and stopping and restarting BOINC seems to allow the app to perform normally. A day or so of normal running allows the CPU efficiency to improve rapidly. I'm not suggesting your problem is the same as mine but the effect of the loss of efficiency is the same.
Cheers,
Gary.
This kind of time-metric
)
This kind of time-metric foul-up often happens when the computer clock is set wrongly - say, somebody clicks the clock in the system tray and uses it as a calendar to see what day of the week somesbody's birthday is next month, then clicks 'OK' instead of 'cancel'. The real damage is done when Windows uses internet time to bring you back to the correct month.
One way of telling if this did happen a week ago is to look at the statistics graphs in the advanced view of BOINC Manager - they'll have some crazy zig-zags.
If it is just a clock foul-up, you can simply reset the metrics as Gary suggested, without losing any sleep over other programs stealing your CPU. Then explain the difference between a clock and a calendar to your kids, or upgrade to Windows Vista, where - at long last - they've fixed this little bug.
RE: This kind of
)
Ahh yes, thank you very much Richard. I knew I was forgetting something common that can cause this sort of stuff up. As usual, I bet you have got it in one.
@JR-Orion, you may need to look at both cpu_efficiency and active_frac in your state file and if either or both are low, you should edit them to be 0.999999 in order to correct the problem. Search for the tag and you will find both of the above parameters in the time_stats block that follows.
Cheers,
Gary.
Hmm, where is the
)
Hmm, where is the client_state.xml file on a Win XP machine? I looked in the BOINC folder and could not find it. Did a search of my hard drive and nothing came up...
My computer doesn't do much of anything when BOINC is off. :) CPU use is at 1 - 5% normally. I do all sorts of virus / malware scans every weekend and the machine has been clean.
I ran into a problem with a PC game (Gears of War) within the last month. The quick and dirty fix was to set the Windows system clock back to a date prior to January 29. I did that, played the game a few times over the course of a week, then set the clock back to normal. The clock has been normal for some time now, but I still get the message.
Maybe that helps some?
Thanks again
RE: Hmm, where is the
)
It possibly confirms the theory about the cause - now to find the fix.
client_state.xml lives where BOINC puts it. If it isn't in the BOINC folder, then you're presumably running one of the BOINC v6 range, which puts it in a "BOINC Data" folder - which in turn may be hidden. Track it down through The Big BOINC 6 Answer Thread.
RE: Hmm, where is the
)
Wherever you decided when you installed BOINC. You may have used the suggested default folder(s) or you may have made your own choice. If you are talking about BOINC 5.x, the default for everything is C:\Program Files\BOINC\. If you are talking about BOINC 6.x, I believe there are separate programs and data folders. I don't know the defaults since I have no BOINC 6.x Windows installations. I'm sure you will find those defaults in the BOINC FAQs. Also I believe that at least one of the folders is "hidden" so maybe you need to use the "folder options" control panel applet to "unhide" your folders in order to find the state file on your machine.
That's where client_state.xml resides on all my machines.
If you got the name right you must have it in a hidden folder.
Which is exactly why you have a problem. If you set the time forward by a big amount, BOINC will suddenly see a very large amount of elapsed time for zero increase in crunching time. It will drastically lower your active_frac (AF) parameter accordingly. As an example if you set the time ahead by 10 days, BOINC would immediately reduce your AF to pretty close to zero. Even after a full 12 hours of additional crunching, AF would have recovered to 12/240 = 0.05 which is still woefully low. Of course, given sufficient uninterrupted running (and no more clock fiddling), BOINC will gradually increase the value to more normal levels and the problem will eventually sort itself out. You only need to edit your state file if you are impatient :-).
Have the messages that talked about 8.3% shown an increase in that value? That will give you a bit of a feeling for how long it will take without user intervention :-).
EDIT: I got interrupted whilst composing my response and didn't notice that Richard had provided one as well. He's given you a useful link too.
Cheers,
Gary.
RE: Have the messages that
)
Yes, because you moved the clock backwards and then forwards, it will probably be correcting itself gradually as we speak. But it might take a month or more to correct itself fully, so you might feel it's worth giving it a helping hand with the edits in client_state.xml - when you find it!
If you had done the more common thing with the clock - moved it into the future and then back again to the present-day - you would have been stuck. BOINC doesn't even start the gradual adjustments until the clock reaches (in the normal course of events) the latest date it's ever been adjusted to. So if you move it forward a year, the corrections don't start for a year. (@ Gary: I sniffed through this code a while ago while researching trac [trac]#588[/trac], and saw several examples of this sort of sloppy programming. That's why I was able to pounce so quickly on DA's insertion of yet another instance in Estimated run-time too high recently).
I am running BOINC
)
I am running BOINC 6.4.5
OK, I found client_state.xml. Found it here:
Data directory: C:\Documents and Settings\All Users\Application Data\BOINC
Sure enough, " application data " was a hidden file.
I suspended BOINC yesterday due to all this, and fired it up again a few minutes back. Here's what I am seeing in client_state
-21600
-
0.999346
0.999867
0.082603
1240695934.937500
I did not see a field for cpu_efficiency
*Sigh* to think this is all from setting the clock back to play a game.
Oh well, on to the fix- sounds like I need to bump active_frac up to 0.999999, and / or just let it run until things sort out?
RE: Oh well, on to the fix-
)
Yes. And don't forget if you want to make the change:
Stop BOINC service (Advanced/Shut down connected client...) and BOINC manager (File/Exit).
Edit client_state.xml with notepad ( 0.082603 -> 0.999999).
Restart BOINC.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: RE: Oh well, on to
)
OK, I just made the change. We'll see how things look in the morning.
Thanks, everyone.