Well, it doesn't really need to be very "constructed", just a configuration I would guess is fairly common for anyone trying to get a DDDT2-badge:
"Run DDDT2-work" + "send me work for other apps if DDDT2 not available".

This can gives series like:

CCCCCCCCCCCCCCC-XXXXXXXXXXXXXXXXXXX

Then there aren't any more C-work available, you'll gradually start filling with X, as you're crunching-down the remainder of C-work. This filling will go over many hours, and many work-requests. Also, since BOINC normally runs FIFO, you won't start on the X's before you've finished the C's. At this point, you'll have basically a full cache of X-work, with short estimated cpu-times due to low DCF because of the C's.

So, going by my example, you'll have 40 X's, each with estimated cpu-time of 0.3 hours, with a 0.5 days cache-size...

Only when the 1st. of these 0.3-hour-tasks has started running, and especially as the 1st. finishes, will it switch into "high priority", but this is often too late...


As for actual DCF, a quick look reveals Rice maxed-out with DCF = 2.55, while C-type's min DCF = 0.234
Difference: 10.9x.

Same here, totto. C-types seem to be sold out as well as HCC betas

Oh yes, the beta show is just going on. Received two more - but no DDDT2 this time.

Ingleside,
Wrong. You are building academic demonstrations, I answer practical questions.
The way the C tasks were distributed today a user had no chance of getting 50. My quad has run the whole day with DDDT2 only (no alternate work allowed) and a cache of 4 days because I have been out several times for a long time and I did not want it to run dry. Note that I don't consider 4 days as a reasonable cache size normally. Even though, this quad has received only 42 C tasks of which it has processed 26 only (several betas HCC in between). And the queued ones are still estimated at 14 hours and 39 minutes. Right now C tasks are no longer available and I dare to hope that the next batches will have a corrected estimated weight.

Had I kept my usual cache size of max 1 day I would not have been able to receive that many C tasks with estimates which were at 40 hours when it began this morning.With this other academic case things are much simpler!
With the current distribution pattern for C tasks and all DDDT2-only devices** being answered "no work available" 3 times out of 4 you would probably have got none at all, and certainly never 15 consecutive ones without any X in between.

** DDDT2-only devices are served before DDDT2+alternate work devices.

I have two valid WU's but what has striken me is the short CPU time.
Less than two hours. When I saw that the norm was tens of hours, I wonder if this is normal doctor?

erlc_ a210_ pr78b0_ 0-- Jupiter Valid 23.03.10 07:18:58 24.03.10 03:27:16 1.30 35.4 / 31.5
erlc_ a216_ pcb006_ 1-- Saturn Valid 23.03.10 05:48:35 23.03.10 22:42:21 1.20 33.4 / 31.2