Don't you worry... when running HFCC in between... got them few DDDT2 C types listed as 83 hours a piece i.e. the 1 day cache is practically annihilated on the quad... just not getting anything more until these have their turn.

23/03/2010 11:26:24 World Community Grid [dcf] DCF: 3.540679->3.288101, raw_ratio 1.014898, adj_ratio 0.286639

We shall persevere.

It's good trickery to control hoovering... pump up the header fpops ;>)

tluehr, no the high DCF prevents overstocking. They will still complete in 1:30 / few hours, so though clients might enter panic state, work fetch stops and work will be well in time completed.

So, when DCFs on all machines get adapted to these wrong estimates, the result would be buffers that are vastly overcommitted when estimates are corrected back to reality or for other WCG projects, and as the result from that we will see more WUs from other projects missing the deadlines and also when estimates are corrected for DDDT2
Now correct?
But hopefully there are not so many DDDT2-WUs with such a vastly wrong estimate to influence the DCF so badly that this scenario happens to the majority of DDDT2 crunchers. As Sekerob already explained: DCF will go down only slowly, but up very quickly.
Nevertheless something that the techs should take care of before the DCFs go down to much.

tluehr,
There could be a risk of overcommitment only if the techs would suddenly underestimate the C-type WUs as much as they have overestimated them and if you have pushed your cache size to the max in hope of getting more of the overestimated ones.

I trust the techs for not doing this second mistake, and you, on your side, you would not have done this big cache increase, would you?

As long as the cache is kept to a reasonable size there is no such risk. What will happen if/when the weight of type C jobs is corrected is that we will slowly get more until their number is in synch with reality.

Cheers. Jean.

Bah....I have had very little luck getting any tasks for my 14 cores, a grand total of 3 tasks since this project started, until today.

I have finally been able to get some tasks for my fastest two machines [face_dance], but one has already errored out. Boo!

erlc_a100_pr78a0

Computation for task erlc_a100_pr78a0_0 finished
Output file erlc_a100_pr78a0_0_2 for task erlc_a100_pr78a0_0 absent

<core_client_version>6.10.17</core_client_version>
<![CDATA[
<stderr_txt>
INFO: No state to restore. Start from the beginning.
called boinc_finish

</stderr_txt>
<message>
<file_xfer_error>
<file_name>erlc_a100_pr78a0_0_2</file_name>
<error_code>-161</error_code>
</file_xfer_error>

</message>
]]>

Anything I should be worried about, or is this normal?