My interpretation always has been that the processing required per position will decrease as the project progresses.

The batches have no apparent pattern in size (see links in the Project progress page)

I'd suggest that as the actual analysis gets easier, then number of positions per parent unit will be increased to maintain the 6-hr processing time criterion.

Hence, the problem won't solve itself. If the parent batch size was to remain the same and the processing gets easier, then this would be equivalent of moving the wall out so that fewer processors hit it. But that's like solving a skills shortage by making the qualifications easier to obtain for the same effort - a politician's solution.

It might be fascinating to check the 'later batches speed-up' theory by moving a small later batch earlier into the schedule - but I'd venture that would really only serve to satisfy academic curiosity.

hmm, now I had me first 12 hour parent job i.e. getting past 60% at 6 hours, and then encountering position(s) that took more to not be able to complete the remain 40% in the next 6 hours:

CMD2_ 0174-2DK5_ A.clustersOccur-2OU7_ A.clustersOccur_ 18_ 0-- 1112084 Pending Validation 12/1/09 17:33:16 12/3/09 15:44:54 12.01 216.9 / 0.0

Now is hoping that the wingjob [reads rotten] also makes it to 12 hours, else allot of redundant positions have to be redone in a child quorum... Will update, whatever comes out.

You're right, think uplinger did, guess or close probably the nearest search term.

edit: found at least one hit on this https://secure.worldcommunitygrid.org/forums/...ead,26542_offset,0#243109

An idea to consider for this situation: Modify the validator so that it can use the same parent to help validate at least one child if the leftover number of structures is great enough.

Rosetta is into simulations and software design. They are interested in 30-40 thousand per target and see how the simulations group together for the best folds, so they can offer these incremental run times of 2 to 24 hours, there not being the absolute quorum issue to deal with. Does not compare to what HCMD2 does. OT, guess what happens if someone sets up a Results challenge... woosh... server overload, where 500,000 daily results ceiling overall is what the Techs are currently comfortable with.

As for the proposal to have a child run against the overage of the parent quorum, I'm sure the techs have thought of that and found no way to fit that into the current server work generation, feeder, validation logic. Already this idea was suggested on the forums, the issue being that it's probably once again a major coding/testing effort, and with the very fine CPU matching, probably a need to send that to a same family CPU to get a sufficiently equal result to match that parents overage... so few hands, so much to do.