Sorry Sek, it must be me. I've got both my pc's (Guitar Man & Guitar Man 1) running on Muscular Dystrophy only. I'm not going to change it.

Can you please e-mail the dollar to me

Sekerob, all my machines have a one day buffer which is not exceptional.
By the way I have stopped crunching HCMDP2 after reaching Sapphire but I remember when I started I got a fall in my Valid WU's and a shot in the number of PV WU's. But this was transitory. After a few days or so it was ok.
When I started with rice NRW it was not the same pattern, much less problems.
With HPFP2 it was horror at the beginning. A lot of errors all the time. An incredible number of PV WU's. I nearly quit. Then I decided to stay and the Valid and PV WU's quantities reached an acceptable pattern, but still with many errors.
Having crunched a piece of all active projects I can say that not one behaves like another. Due to quorum, or mirror WU issues, errors etc.
But my feeling is that there are less problems with projects that have WU's which finish in 2 or 3 hours then those that finish in 6, 7 or more hours.

French humor I guess PV/Daily Ratio, so if doing 50 a day, 50 are stuck in PV jail. Nope, my ratio is higher.

Out of the last 30 mostly parents, only one stopped at 6 hours, none reached 12 hours... lighter stuff as observed in the crunching chart thread.

No, I was serious. In the Linux playground, with a practical cache of about 0.7 day (cache at 1.0 and on_frac between 0.6 and 0.7) my PV is varying around that size and very few WUs are waiting more than one day.
In the Windows side my P4 is permanently crunching HCMD2 with a return delay of about 20 hours and there are only 2 PV jobs right now. I think it is usually a little higher, but not much, for an average 8 WUs a day.

I am switching the Windows profile of my quad back to HCMD2 to see if it is much different with a faster machine.

Cheers. Jean.

Now here's a feature that could be incorporated into BOINC, if only crunching for WCG [with a buffer]. We know WCG can cause redundant jobs to abort, so why not set a flag for the client to fetch at each server contact, to signal that task xyz already has a matching wingman. Sort of an project internal round robin, pre-empting jobs that have not yet a match. The gain is a one time reduction on the server side of the PV pool, shortening maybe the Result Status pages and earlier completing batches, to reduce storage requirements (if they are still considered a premium issue). There'd be a bringing forward somewhat of credit award for the volunteers too. Of course, the smaller the caches, the less there'd be in PV and with the superior project stability it being only a question at client side: Do I need that biggish buffer?

(think my brain hurts already just by the thought of all the permutations needing adding to the schedulers)