Computation Time Length
10 Apr 2008 17:25:44 UTC
Topic 193621
(moderation:
I thought that this would go away, but it's been in my face for the last 4 months, and shows no sign of clearing up...
I'm running on IE6 and BOINC ver. 5.10.44 When a new task (WU) downloads from Einstein, the estimated time for computation is wildly out of sync with the actual, causing BOINC to think I'm in 'time-crunch'
E.G. a WU that only took a little over 40 hours of CPU time was originally scoped to run nearly 2400 hours. Perhaps there's a file somewhere that is stuck/corrupted, but I've detached and reconnected a couple of times with no relief.
Comments and/or suggestions, please. Thanks ...
If I've lived this long - I gotta be that old!
Computation Time Length
)
What are your time statistics
- either from the bottom of your computer summary on this web site (you can see those details, we can't), or from client_state.xml
Do they make sense for your computer? (List them here, and point out any which seem wrong).
OK -- here's what I see in
)
OK -- here's what I see in the client_state.xml :
ON = 0.999880 (this figures, BOINC runs as a service)
ACTIVE = 0.999939
EFFICIENCY = 0.821648
Duration Corr Factor = 86.474685
I have no idea how these values compare, so I bow to your knowledge ...
If I've lived this long - I gotta be that old!
RE: OK -- here's what I see
)
Duration Correction Factor is the one which is out of line, and would account for your symptoms. The value is nominally 1.000000, and often lower (especially if you use power apps here, or optimised apps on other projects.
It will correct itself slowly (very slowly), over time, or if you're feeling intrepid, you can help it along.
Usual rules apply - stop BOINC first, take a backup, at your own risk, etc. etc.
Then - having checked that BOINC is fully stopped - use a plain text editor like Notepad to change that DCF in client_state.xml to 1.000000 (keep the format - six decimal places - and be careful not to disturb any of the tags or the rest of the layout). Then save it, and restart BOINC. You should have a much better estimate immediately, and it'll sort out the final correction over the next few days.
Thank you !!! I can
)
Thank you !!!
I can correct the value quite easily, but I will make a copy of the file first, just to be sure. Thank you for your assistance with this .....
If I've lived this long - I gotta be that old!
RE: ... I will make a copy
)
Actually, making a copy of client_state.xml is relatively useless. The system has its own backup copy (called client_state_prev.xml) and if the main file becomes unreadable or unparseable, BOINC may be able to revert to the backup.
The biggest problem for people editing the state file is that a wrong change may invalidate your local conditions which then gets immediately communicated back to the servers. Once this happens, no amount of restoring a good backup is going to save you. If you are going to make changes you are not absolutely sure and comfortable about, the better technique is to backup the entire BOINC tree and turn off (suspend) communications with the project beforehand. Then if an edit goes pear shaped, at least you can blow everything away, restore the backup and be back at where you were when the backup was taken with the servers none the wiser :-).
In your case the editing of a DCF value is pretty routine and not easily stuffed up if you are paying proper attention. In this case, a full backup would probably be a bit paranoid :-).
It might be useful to ask yourself how could the DCF value have got so distorted in the first place. You say this condition has existed for about 4 months. A big worry is that it didn't appear to self correct in all that time. If a task takes about 40 hours and BOINC's estimate was around 2400 hours, when the task is finished BOINC should reduce the estimate for a subsequent task by 10% of the error - ie around 236 hours. The sheer magnitude of the discrepancy should have resulted in some fairly obvious corrections early on and after 4 months you should have been basically back in the ball park. Unless of course something is happening periodically that throws things further out of whack each time. Can you think of anything that seems to periodically exacerbate the problem?
Also, I notice that you support quite a few projects and that E@H may have a fairly low resource share. Perhaps this is the reason why it's taking a long time to self correct. You may be interested in improving this - not by changing resource shares - but rather by reducing the time it takes for a task to be completed. There is a "power users" version of the science app that is considerably faster. Your 40 hour tasks would probably take less than 30 hours if you were using the fast app. If you are interested, let us know and somebody is sure to point you in the right direction :-).
Cheers,
Gary.