I'm willing to dissect the patient!

<time_stats>
<on_frac>1.000000</on_frac>
<connected_frac>1.000000</connected_frac>
<active_frac>0.000076</active_frac>
<cpu_efficiency>0.977400</cpu_efficiency>
<last_update>1293258597.968750</last_update>
</time_stats>
<net_stats>
<bwup>3792.407780</bwup>
<avg_up>564740.115592</avg_up>
<avg_time_up>1262484459.843750</avg_time_up>
<bwdown>9814.780478</bwdown>
<avg_down>770666.854625</avg_down>
<avg_time_down>1262469224.953125</avg_time_down>
</net_stats>
Noted, but I'll wait... until you've "picked my brain clean" (does that translate?)
Thanks and Cheerful Regards! Bruce

You've overlooked one very important parameter:

Since 1290* is November 2010, would guess 1293* most likely is in January 2011, or maybe December 2010.

In any case, it's a completely wrong date, and the very low active_frac is due to this. Also, since is running v6.2.xx, the time-stats won't be updated until after the "last updated"-date (meaning around 2011)...

To fix, the easiest is just to shut-down BOINC, making sure BOINC isn't running (use task manager). Afterwards, open-up client_state.xml in something like notepad, and just remove the whole <time_stats> </time_stats> -part of the file, and save it. On next startup, all parameters will be back to 1 again, and working from there.


It's also possible to edit the active_frac, but if so you'll also need to edit <last_updated> to something like 12626*. But, this gives more room for errors, so my recommendation is to just delete the whole time_stats-block.

As for client_state_prev.xml, it's not neccessary to edit this file, since it's only used in cases can't read the whole client_state.xml-file.

Thanks, and a happy new year to you and everyone else.


It would be nice, but not very important after the various changes included in later BOINC-clients. It was probably v6.4.x that started detecting if the date has been set in the future, and starts updating time_stats again. And v6.10.xx doesn't decay the time_stats if client has been off for more than 10 days, since this most likely is due to a holiday and not due to user running client very infrequently.

The deadlines will most likely get screwed-up, but these is human readable in the manager.


Can only guess, but these errors most commonly is due to user-error, by user manually changing the date and afterwards correcting it again. Seeing it's just active_frac that's very low, this has been done while BOINC-client was running.

Another possibility is a bad battery so losing the clock on power-off, but this normally resets the date somewhere in the past and not in the future. Also, this would give very low on_frac.

It's possible, but not very likely, that an automatic time-synch has been severely wrong.

This latest code insert, the underlying details I don't know, infers that work will be fetched when cores are idle... but then, cores should not have been idle to begin with on mitrichr's I7, no matter what cache setting

David  12 Jan 2010
350 	    - client: small tweak to work fetch:
351 	        if project has crazy DCF, don't automatically request 1 sec;
352 	        only request work if there's a shortfall.

This is coming in a next release for Windows I suppose, i.e. after the latest 6.10.25 alpha and curious if it does fix the I7 issue.

Edit: And this one, well, I take code knowledgeable assertions how it should work versus how it does work anyway with reservation... I believe it when I see it. The last line is telling, and that's from the chief developer ;>)

David  5 Jan 2010
92 	    - client: scheduling problem:
93 	        - a project overestimates job FLOP counts
94 	        - the client starts jobs in EDF mode
95 	        - as job progresses and fraction done increases,
96 	            its completion time estimate decreases until
97 	            it's no longer a deadline miss.
98 	        - job gets preempted by other job from that project;
99 	            you end up with lots of partly completed jobs.
100 	        Solution (I hope): if an app version has running jobs,
101 	            compute a "temp DCF" for the app version,
102 	            which is the min of dynamic/static estimates for its jobs.
103 	            Apply this scaling factor to completion time estimates
104 	            for unstarted jobs in RR simulation
105 	    - client: the estimation of remaining time of running jobs was wrong
106 	        (how did this bug survive so long?)

Maybe we get now more accurate and quicker adjustment of the TTC's :D

Well, the temp_DCF was removed again with a comment that it did not work.