I remember this chart. It was very helpful Sek. This type of information on each project, if updated daily automatically (I don't mean by you), would be very helpful to the crunchers as would being able to see what is going on with the available and returned WUs. Any chance of getting that on the website wishlist? As far as I know the DDDT-2 Global Statistics page is the only data about the project that one can view. Is that correct? If people could see what is going on, they would be less impatient. The same argument goes for next bus/train signs. People are happier when they can see when the next bus/train is coming, even if it doesn't come any faster. People don't like the lack of information.

Cheers

Let me take some of the heat off the CAs, thought they are far too prefessional to ask for any help.

Reading the posts in threads like this one reminds me just how much effort it takes to teach people about how WCG works. There are three major fallacies that keep being brought forward:
1. That the opinionated demands of one, or a few, crunchers expressed in the forums mean that something has to change at WCG.
2. That the crunchers are the customers.
3. There are people standing around somewhere inside WCG who have been waiting around until some all-knowing volunteer comes up with a job for them to do.

All of these are very, very wrong. If you support the common political idea that one person who speaks up is speaking for 100 people, then you will need 500 posts to support an opinion. of the hundred ideas expressed in the forum, I have seen maybe 2 that have had 50 people express the same opinion, in the last 2 years.

As to the second point, the Customers of WCG are the Scientists. You the cruncher are not the Customer. The Scientists are who WCG needs to make happy. We are the volunteers and while it is in the best interests of WCG to have happy volunteers, our happiness is no better than third place, after the Techs.

WCG does not have a spare moment to waste on new ideas. There are several really important features that WCG needs to add to the system and there are no hours of labour available to do the task, AND I am not talking about a truly ridiculous idea of hourly tweets. There is no one to do it, even if there are five crunchers who think they should demand it.

The solution is quite simple. Find a project you like and crunch it. Find two. Change projects. If you decide that DDDT2 is not a project that will benefit humanity, then go find a prime number. If you want more points join Collatz.

Whatever you decide, DO NOT for a millisecond start to think that the 5 WU you crunched yesterday somehow make you important, when there are 100,000 other crunchers who finished the other 483,992 WU yesterday. I am in the top 600 All-Time for run time. If I leave tomorrow, sure WCG would wish I stayed, but I have NO misunderstanding of just how insignificant my 24 Million points is compared to the 192 BILLION total.

Enjoy your stay here at the WCG hotel, spa and resort complex. We welcome your ideas and we will forward those ideas that we determine are of interest, to the professionals who will decide if they are valuable. If you happen to submit an idea that we have previously discarded, it will be treated similarly.

Good day

Well setting aside the inflated ego about deciding the worth of passing things along and such, I think that many of the advisers need to step back and understand that:

1. Most of us "whiners" more then understand the lack of work sent and how things went down. Yes we do read a lot of your posts and find them lacking at times.
2. We also understand that it is not a constant flow and therefore intermittent.
3. For heavens sake we all understand it is for the science and not the badges, but the badges are here and there are a lot of us who enjoy the competition. That is an added enjoyment to crunching...or at least til it becomes biased.

The list goes on, but I think the biggest complaint at least with the launch of this project and many Beta releases is how they are distributed in the "lottery" analogy from above. I understand WCG has not written code to babysit distribution to be fair to all, but that doesn't mean it can't be improved. I'm sure putting a limit on how many can be cached at a time would be an easy step towards fixing things. I know I waited a long time to get my first unit and just turned in a resend from a server abort. There should be no reason for Ruby badges to be earned before someone with over 20 computers gets just one. But that is the case and that tends to be a pretty good argument.

GIBA,
I try to never forget this sentence that Evelyn Beatrice Hall has written as an illustration of Voltaire's beliefs, "I disapprove of what you say, but I will defend to the death your right to say it", although I hope to never have to go that far.

Consequently, if you think that all 5 numbered items in the part of my post addressed to you are opinions you are perfectly allowed to think and write it.

However, for people more interested with real information and facts about how WCG is currently working I insist: those five items (between "GIBA" and the PS paragraph) are mere facts, not opinions of mine.

Cheers. Jean.

Coleslaw,
I don't know if you missed it or not, but since the latest beta test (the new version of HCC if I remember correctly) such a feature has been put in place, and since it is a real improvement on both aspects (return speed and "user fairness") I do think that this improvement is here to stay, i.e. it was not specific to this particular test. Here is how it works at servers level:
Servers will ensure that, at any time, no device has more beta WUs "in progress" than it has active BOINC threads.
A monocore will never have more than one beta WU active or waiting to start,
a quad not more than 4, an i7 quad with HT ON not more than 8, etc...

So much for the rule.
Note that, if the stock of beta WUs to distribute is big enough for the distribution to last longer than the time to crunch one, a device which reports one completed beta WU will be entitled to receive a new one.
This feature could be implemented because it is not impacting access to the main database. Each work fetch request from the BOINC client contains information about its jobs in progress, therefore each request can be applied this rule without needing any extra database history access or, worse, redesign.

The immediate effect of such a rule is that more devices will receive beta WUs and if priority settings enforce it more beta WUs will be starting immediately. This is how it improves the response time (the main objective) and how it increases the chance for more devices to receive some (the second objective), thus enlarging the configuration scope of the beta and "user fairness".

On April 2 I have asked in the CA forum if this new rule could be easily applied to DDDT2 type A WUs, and possibly to type B too.
No answer yet (it was Friday and the techs are not always working 7 days a week ) but I am sure this question will be considered (if it were not already in their mind).
We'll see.

For small distributions luck will always play a great part, even with the new feature above, and the key point will still be if a work fetch arrives at the right time, i.e. while there are WUs to distribute.
So a quad issuing 100 work fetch requests per day will always have more chances than a P4 issuing less than 10.

This is strictly true for beta WUs which are the highest level of distribution priority.
For any project with limited distribution other distribution priority levels also come in the game as follows (from highest to lowest):
1. devices fetching this project only with no alternate work allowed
2. devices fetching this project only with alternate work allowed
3. multiproject devices.
Needless to say, when distributions are in the range of a few thousands only, most WUs will go to category 1.

Regarding Ruby DDDT2 badges (or even higher) there are not that many and most have been earned by members who could cache lots of long type A WUs during the first distribution (i.e. before the reliable distribution rule was set). At 30-40 hours each a Ruby badge was meaning only 108-144 WUs, which is not that many for a user with several quads.

Last point, all mechanisms above are at device level. Introducing limitations at member level would add so much complexity and operating load on the main databases that I doubt that it has serious chances to happen. But this is a personal opinion only (hi GIBA ) and I may be completely wrong.