Reread my post: "Pending Validation" has not gone through the validator yet, so it is not part of the game for condition #2.

And to save you one question I would bet that "inconclusive" are ignored too, but this has to be confirmed by knreed.

Cheers. Jean.

To clarify Pending Validation in any Quorum distribution meaning: The result was by all known work unit controls completed without any anomalous conditions occurring and thus not up front "Invalid" or "Error" or "Inconclusive". Where a result in the case of Zero Redundancy is dubious or in Quorum 2-10-14 is not within tight quality control parameters or not bit for bit identical (method depends on project), the task(s) are marked "Inconclusive" and additional copies are send out for verification and validation.

"Invalid" means that the unit was completed locally within standards, but on further checks by the validators found to be incorrect. 50% credit is given for work done, based on the valid units in a quorum.

Plz see FAQs for further explanations, particular the Result Status page XYZ FAQs.

There is no mechanism, but the mechanism knreed described to assign a due-date to a job. This can be overridden by the techs at any time.... the 20% rule is not in stone. e.g. some rush jobs or betas gets 24 hours or less depending on how long a job is. The client itself has algorithms to make sure all goes to plan and all jobs finish in time.... that is if the power in on.

I think if WCG could cause for due dates to change on work you have already downloaded very many people will get upset that not only crunch for WCG! Picture different project techs playing against each other to get that job you have out on front. knreed has the master key to the joystick and uplinger has the chopper controls and they occasionally do odd stuff late at night, at the office

think I watched 1 too many Leslie Nielsen caper scenes?

Barney, you forgot two cases:
0.1) It's already completed and uploaded and will be reported with the next request for work before the due time (still 2 h and 18 mn when you sent your post)
0.2) It's not yet completed but it has started early enough for being finished , uploaded and reported before the due time.
Also, note that regarding the 3rd instance to be re-dispatched case 1 is the same as case 2 from a scheduler viewpoint. Only when the WU will be complete on the server will we know if your partner was late or not responding.

Regarding assumptions on the queue size of this machine we (you and me) simply don't know. It can well be that it is a not recent machine that its owner is using as in the basic Grid Computing definition, i.e. it is switched on only when its owner needs it and it takes that many days to reach the end. If that is the case and the settings are the default ones I would rather see things this way:
1. WU "A" takes about 4 elapsed days to be processed
2. a few hours before completing, a new WU "B" is requested and wait as "ready to start"
3. WU A completes and starts uploading its result files while WU B starts processing
4. a few hours before WU B completes (i.e. about 8 elapsed days after the start of WU A) a new WU "C" is requested and WU A is reported.

I am sure there are thousands and thousands of such machines in "normal members" homes, or in the farms of some participants who collect everything with a processor inside to boost their statistics (maybe a little less nowadays with the current costs of energy ).

No problem, it's always interesting to share different points of view and to try figure things out as accurately as possible.

Cheers. Jean.

faah5011_4fiv_1hbv_00_2 took more than 40 hours (can't tell exactly)








.