I've been wondering about this, too.
Associated with the method of validation is the question of what positions does the wingman get when I get a child or later-generation WU?

Here is a scenario. I forget how many total positions there are in HCMD2 WUs, but for the example, I'll assume 600.
Starting with a virgin WU, cruncher A completes all 600 positions.
On the 2nd stream, cruncher B does 200.
I'm cruncher C and I get positions 201-600.
What does my wingman (D) get? My Results Status says that he always gets a WU with the same name as mine, except for the last digit that is the number of the copy. If he really gets positions 200-600, this means that these positions will get to be crunched 3 times. If C and D do not both complete their 400 positions, yet another duplication of crunching will be added. Et cetera. Such a system would be very wasteful.

Or are cruncher D and his WU imaginary, with his WU made up of positions extracted from result A? The latter scheme would be most efficient, and also simplest to implement. A new WU would be split into 2 streams. Each stream would be split into as many real WUs as needed to crunch all positions. The initial, parent WUs would be real and identical, while most other wingman WUs would be imaginary. For any WU returned, when all corresponding positions in the opposite stream have been crunched, the imaginary wingman WU could be synthesised if necessary and validation could proceed.
Comments?

Well, I'll join the puzzled club.

Suppose we have IDENTICAL machines which process 40% of a WU in the allotted time.

The second generation would appear to be FOUR tasks, starting at the 40% mark and completing to 80%

We'd then have a third generation, with EIGHT tasks.

There would be massive wasted effort in this case.

Suppose we have one machine twice as fast as the others so that the first generation returned results at 40% and 80%.

The next generation could be TWO tasks started at the 40% mark, wasting the extra processing by the faster processor and effectively limiting the processing speed to the SLOWER of the processors selected.

OR the next generation could start at the 80% mark, violating the entire concept of matching, and hence unlikely.

Any other way would seem extremely complex to implement - perhaps tying to combine the 40% processed only one with the 20% totally unprocessed and split it between two tasks. Very ugly - and does not seem to fit with the numbering system for later generations (whereas the start-at-40% and start-at-80% scenarios would - both next-generation tasks carry the same number, bar the replication number.)

And it can't be the case that a task is simply completing a partially-completed task, as they ALWAYS appear in pairs.

If only the incomplete part was being passed on, every generation beyond the first would have a unique start-position number as part of its task designation.

I regret that the "homogeneity group" argument also doesn't hold water. knreed is concerned in that thread about the difference between SSE2 and non-SSE2 processors. From my own results, I have instances where my crunching partners have apparently taken between 36% and 142% of the time I took to crunch what appears to be identical tasks. This means that within my "homogeneity group" there is nearly a 4:1 speed ratio - which must be far greater than the SSE2/no-SSE2 scenario.

I theen' someone has some 'splainin' to do...

"... then even great-grandchildren. Those I've not seen for a long time." The greats aren't so unusual. They get a short return date, so you have to be a fast returner to get them:
> CMD2_0132-ARAF.clustersOccur-3BT2_A.clustersOccur_0_17879_22158_21086_22158_21655_21907_0 | rjb-a64x2 | Pending Validation | 26/10/09 09:11:25 | 26/10/09 17:25:03 | 0.14 | 2.2 / 0.0
It's the great-great grandkids that are unusual.

Example: Parent workunit is set up to compute 1-20,000.

Parent Replica 0 computes 1-5,500 in 6 hours
Parent Replica 1 computes 1-5,000 in 6 hours

Validation occurs on structures 1-5,000. Structures 1-5,000 are saved. Credit is awarded to parent replica 0 and 1 based on upon the average credit per structure (thus replica 0 is awarded 11.1% more credit then replica 1)

Since child workunits are required, the back-end code determines that the most structures that should be computed by a child workunit will those that could be computed in the 6 hour basic limit by an 'average' computer. This results in the following new workunits.

Workunit A: 5,001-8,750
Workunit B: 8,751-12,500
Workunit C: 12,5001-16,250
Workunit D: 16,251-20,000

This process then repeats if necessary.

For a set of 7 batches that finished yesterday, they had the following distribution of parents, children.....

8372 Parents (26.9%, cumulative: 26.9%)
18248 Children (58.7%, cumulative: 85.6%)
3943 Grandchildren (12.7%, cumulative: 98.3%)
507 Great-grandchildren (1.6%, cumulative: 99.9%)
25 Great-great-grandchildren (0.1%, cumulative: 100.0%)

While most of the Children represent 'splits' (i.e 2 or more children are created). The majority of the grandchildren are 'finishers' (i.e. only 1 additional workunit was created to finish off the workunit).

If a descendant is required, then the difference in structures between what one host computes and what the second one computes is discarded.

It is important to note though, that most workunits have no descendants. Those that do generally have a small number of structures that are computed by one host and not the other. There is a very small percentage of work that is 'lost' due to this technique.