Thank you for the information :)

Yves, think you're beating horse, dead so long, the earthworms have digested the last remains. The cache setting workaround has always been to give it a small enough value to not inflate the total cache over 10 days... 2 to 8 hours is divisor 4 i.e 1 or 2 days setting would hardly cause any task to not make it in time when DCF trundles between 0.25 and 4.00 where up is instant and down is slowly so as to prevent over-buffering. In case repairs get assigned, the client is programmed to automatically put them ahead if not making their 4 day deadline. The more variable, the smaller the recommended cache/buffer setting is.

Whilst, knreed could disable the DCF value that is signaled by a client with server version 700, except FTM he's decided against the mechanism as currently implemented. Can't remember why... the mix of old and new clients could be a drawback. What I know of the new client is [observed multiple times whilst continuously running latest test versions], that if the minimum work buffer is set equal or greater than half the shortest deadline time, high priority management kicks in... EDF. Don't like it, but that's the only way to actually have multiple days cache, as the MaxAB does not get filled in full, because WCG [only] gives maximum of 30 WU's per fetch call which is usually enough to lift the buffer above MinB. Else, if the crippled horse needs beating, join the alpha mail list and report your concerns/findings to the client developers at Berkeley's Alpha Mail list. Few over-there seem to speak for WCG.

Hi:

I too have suspended crunching on other project so I can help in wrapping up HCMD2.

If you consult the graph at http://i137.photobucket.com/albums/q210/Sekerob/WCGQuickLook.png, you will learn that this project is in mop up operation. Batches 2500 - 2544 are involved in this operation. I have just downloaded some batches numbered 2518 so the mop up operation is almost 50% complete.

Clive

We are now 67 days into 2500-2544. Strictly speaking, if children of 2518 are going out and the order is still fairly sequential, 2519/2544 = 43% of the first offspring have gone out. The thread indicates somewhere when the first children went out, so child batches 45/19*xx days since circulation started, would give a ballpark of days left of full supply of this generation. Guess it would have been around July 15-18 that almost entirely children started to get validated [no more parents in any numbers]. Based on the last 7 day validations, a fair extrapolation can be made of how many said children [quorum 2] are still to go out, but round about 2.5 to 3 weeks more is the edge of envelope calc

83,940
81,928
83,801
86,209
88,686
84,880
87,520

BTW, the weighting in CPU years is not full [in results it is]. HCMD2 runs about 9 years less daily as the top 5 in the pack: http://bit.ly/WCGQLK

[waving all and every responsibility for these out of thin air 2 cents ;].

2 alex33: I also wish I have paid more more attention on English language lessons in school(s).