SekeRob - Have the PhotoBucket folks ever mentioned when they will get their stuff fixed so we can bring up your WSG Progress Charts again?

Sgt Joe makes an important point:So lets run some numbers. Yesterday we finished 3,199,212 hours of work on 771,136 WU for an average of 4.1 hours per WU on 234,816 devices or an average of 13.6 hours per computer per day.

Also, the top 100, just 1/10th of 1% of the crunchers, did 24% of the work. I call that getting the job done.

I see virtually no return on investment by introducing inefficiencies to WCG to cater to 3-5 hour/week contributors when the next new $450 Quad added to WCG can contribute 75+ hours per day.

Without names, one active member has returned 320+ WU in 83+ days of crunching over the last 6.5 years. Yesterday, I completed 712 WU in 23+ days of crunching (and I am only rank #436). Are we grateful for those 320+ WU. Absolutely. But not at any cost.

astrolabe, point well taken that the top crunchers are doing a lion share of the work. Another view is with these large WUs, I would bet that one reason that active user you pointed out managed to do so much limited work may very well have been due to them passing back 'No Reply' after 'No Reply' and not getting many WUs to 'Valid'. Now from your view, such a user I suppose such a cruncher would best just go into the sunset never to see the light of day again, when the reality is that if that cruncher either was given WUs say 1/2 or 1/3 of current sizes or given more time to crunch their work, such a cruncher might very well increase the amount of work they complete by a non-trivial amount. Now the only way to see if such changes would work, someone who has access to more detailed data could easily take a closer look at the logs of a small sample of smaller crunchers and see if a change or two would make a decent improvment to the WUs workloads completed - basically a not too complex PCM analysis. If someone has access to the data but doesn't have the time to analyze it, I'll even offer my own volunteer time to look at this data and see if there is a equitable solution to this issue.

Something else is at work. We've had extensions before without impact [much bigger ones], causing an initial slight delay in validations during the transition period. Possibly the really big contributors have become more energy conscious [big contributors on 24/7 is big energy bill their comptroller will see]. There's one big one that nearly halved the years contribution, which started in Q1-12. Except for the charts info all can see showing the 6 month [eyeball] trend, with the little trend spark-lines on the dashboard to give an overview impression. Beyond that, my [free] time is limited.

EXACTLY what I was thinking, maybe the Project could determine what processor a particular machine has and then issue units based on that, ie an Atom would get shorter running units than an i7 for instance. Maybe an Atom unit would be half the size of an i7's unit for example, or 1/4, 1/8 or whatever. Essentially exactly what we do now, the project has one big unit and split into many parts and we each crunch our part and then the project puts it back together into the big unit again for the result. Just split it smaller for less capable processors. Of course once split running that little bitty chunk on an i7 would be silly, so some Server programming would be needed to keep it all straight. Resends could be handled the same way OR sent to faster pc's just to finish them up.