MM,

Yes you missed it ;-)

Per Uplinger all jobs for a single compound are now cut into 2 parts just enough to be able to run them without having to recompile the software for more dockings per WU (I've counted 43 on several sequential jobs). This approach is regardless of the toughness so you can see jobs depending on device from 2-4 hours to 20+.

And as anhhai noted, when completed job durations go up, the TTC estimates for the rest in the buffer follow... until enough 'normal' are run again to bring that value back down. TTC reflects current going actual average... going up fast in the client and only slowly going down... to protect those that like to run with big caches and than suddenly have a client running in High Priority mode.

cheers

The work fetch actually auto suspends till the buffered value drops back to below that 3 day objective. If you look in the message log and have the scheduling debug flag on you actually see for instance:

Thu Sep 9 06:56:21 2010 WCG Requesting new tasks
Thu Sep 9 06:56:21 2010 WCG [sched_op_debug] CPU work request: 133101.82 seconds; 0.00 CPUs
Thu Sep 9 06:56:22 2010 WCG update requested by user
Thu Sep 9 06:56:26 2010 WCG Scheduler request completed: got 8 new tasks
Thu Sep 9 06:56:26 2010 WCG [sched_op_debug] Server version 601
Thu Sep 9 06:56:26 2010 WCG Project requested delay of 11 seconds
Thu Sep 9 06:56:26 2010 WCG [sched_op_debug] estimated total CPU job duration: 139303 seconds
Thu Sep 9 06:56:26 2010 WCG [sched_op_debug] Deferring communication for 11 sec
Thu Sep 9 06:56:26 2010 WCG [sched_op_debug] Reason: requested by project
Thu Sep 9 06:56:41 2010 WCG [sched_op_debug] Starting scheduler request
Thu Sep 9 06:56:41 2010 WCG Sending scheduler request: To fetch work.
Thu Sep 9 06:56:41 2010 WCG Requesting new tasks
Thu Sep 9 06:56:41 2010 WCG [sched_op_debug] CPU work request: 8395.40 seconds; 0.00 CPUs
Thu Sep 9 06:56:45 2010 WCG Scheduler request completed: got 1 new tasks
Thu Sep 9 06:56:45 2010 WCG [sched_op_debug] Server version 601
Thu Sep 9 06:56:45 2010 WCG Project requested delay of 11 seconds
Thu Sep 9 06:56:45 2010 WCG [sched_op_debug] estimated total CPU job duration: 17413 seconds

X seconds of work are requested, which is the difference of current cache to top it up to 3 days and Y seconds send. Usually just one call on a steady running and backfilling machine. The Y seconds lifts that cache usually over the 3 day requirement as no job exists to give the exact amount of work, so in the last call 8395 seconds were asked and 17413 worth were received.

Good tool to follow cache size is BOINCTasks. In the Projects tab it gives a Per Core amount of time that is buffered, including the work already crunching. Now it shows 2:01:35 days per core where my cache is set to 1.9 days... just below that famous 2.0 days R++ rating level so repair jobs do come this way (of rare work)

Crunching On

:D

yes,seen the info.
No more worries, Pulled the X5687's today and dropped in X5690's..
They won't show up on the charts as this machine is in Jon Magoon's name(loonym)
He passed last Dec 28 from Bladder cancer.
Some of us at XS forum are making sure he isn't forgotten and his account doesn't drop in the stats pages.
It's a small thing but the only way I know to say we haven't forgotten you.