Snow Crash, So more people can contribute to the Beta program,
tasks get allocated to more different system types,
and to expedite the process.
If you ran all the tasks they would only be tested on 3 different operating systems, it would take longer to complete them, and fewer users will be involved; I prefer inclusion.
My initial suggestion was and remains open to discussion, and further suggestion. It was never meant to be definitive. From the discussion thread, limiting Beta work unit allocation would need to be better defined to facilitate specific types of testing, such as testing on different operating systems, hardware architectures and to facilitate running different numbers of tasks simultaneously. Something that different methodology could perhaps (or not) better cater for, hence the question.
I am perfectly within my rights to question! I never suggested that testing multiple task runs simultaneously was not a good test parameter. However, it is not the only thing that needs to be tested for.
With only 633 tasks available, it was always going to be difficult to get tasks distributed across a representative variety of computer architectures and operating systems. So running 4, 6, 12, 24 or more tasks simultaneously on one system in itself substantially reduced even task distribution across different platforms and architectures, and arguably limited the effectiveness of the tests.

What I see is a balancing act between running multiple tasks on one system and seeing how tasks perform on different hardware architectures and operating systems. So I think it is fair to question methodology that on the surface would appear to tend toward testing multiple tasks runs.
I think you have to draw the line somewhere WRT multicores. If someone has two i9s in a dual socket system they could crunch 24 tasks at once. Cache 2 or 3 days worth of tasks, and all the Betas get run on around 10 systems. A very limited form of Beta testing!

If you wanted to look at the ability of a system to crunch 24 tasks simultaneously on one operating system, then another operating system and so on, you would run out of tasks fairly quickly, and would certainly not get an even performance representation of computers hooked up to the WCG. With the limited number of tasks released and the growing number of CPUs and systems, to me it would seem more reasonable to distribute the tasks as widely as possible, but perhaps the scientists and techs think it is more important to test multiple tasks for some technical reason I am not aware of.

The tasks were released in one phase, night time in Europe. Perhaps three batches separated by 6hours might be a better way.
Whatever the results of this round of Betas, there will be more.
If the methodology stands up to scrutiny then there is no problem. If not, then there will be more task failures. Still not a big problem for me, but I would prefer to know that my electric bill was high because I was returning successfully completed tasks. If I highlight a possible problem and someone rectifies it before it becomes a bigger or improves a system then it was worthwhile. A scientist that cant stand having their work questioned, is in the wrong job. If the method is perfect, I still have no problem.
All I am doing is throwing the question out there. Was the system used the best way of testing (is allowing tasks to be allocated by the existing delivery system desirable)? Should an alternative be considered that would allow for more direct planning and allocation of tasks; in order to ensure tasks go to enough different systems to know that they will work universally?

Enjoy your Christmas,

28 cores here but, as usual, no beta WU's for me. I'll try brinktastee's suggestion:

I've been fulfilling the coffee part, but not the rest

Uplinger,

I understand there are 4 parts in this beta, one internal in WCG, then "A", "B", and "C" with the "B" WU's coming from the "A" results and the "C" WU's coming from the "B" results.

Now, a question: As "A" has been distributed already, will you release the "B" and "C" WU's in bulk, or do you release the "B" WU's at the moment that their parent "A" is confirmed and processed?

In other words, will it be it a trickle, or a mini dam burst for the B and C work units?

To expand a bit on that statement, We will be releasing them in the form of batches. Examples are best way to show :)

Researchers send us 2000 type A work units for a given target. They are split into (for this example) 500 work unit batches. When all 500 of 1 of the 4 batches complete, then we'll send that back to the researchers for them to create type B's...So there could be some A's still running when the B's start. Also, as i mentioned target before, there could be multiple targets in some stage of processing. This means target 1 may be finishing up the type C's for it's target, yet target 6 is just starting type A's and the other target 2-5 are running some type on the grid.

Please note, the numbers provided were for an example :) If they do turn out to be accurate, then I will be very surprised.

JmBoullier, thanks for finding that post.

-Uplinger

On 20 Dec, 2009 @ 22:34:25 zulu, in http://www.worldcommunitygrid.org/forums/wcg/...ad,28160_offset,50#261382 I replied,


OK... now I agree the hopes for a new beta badge this year are dimming.

Happy 2010, everyone.
(darn - there's not a party-hat-smilie in the bunch.)