There's no custom sizing according to hardware power, only an effort to set a duration target, so that all platforms can participate. E.g. because Android gets to work on the AD Vina driven sciences, this platform is putting a constraint on how big tasks can be sized (which is not based on MB, rather on runtime). Yes, dynamic sizing to power would be something on the tech wishlist, if only they knew up front the FPOPS needed for any given molecule or protein target. They don't and time and again find complete chaos.

No, far as observations go there's generally no increase of runtime as the project progresses. Maybe CEP2 was the exception, but then when a new experiment started, it would reset again.

For the 'making it up as they go' department: The performance of WCG is completely unhinged from Moore's law... computing power averages here barely increases 5-10% per annum, nothing close to the doubling every 2 years.

FYI for any interestee: A new config tag will be added, which allows clients to compute the estimated runtimes purely based on benchmark. IMNSHO, if WCG keeps smoothing and plugging the running FPOPS averages into new work, the estimated runtimes will still be off off. The tag is only of value if there would be truly a reasonable accurate FPOPS on a per-task basis. So far, just a ... dream


Not sure how this all is going to work, considering that WCG also runs with the <dont_use_dcf/> control, disabling a client of adjusting estimated runtime based on true performance.

BOINC has an initial 30 second Benchmark test split in Float and Integer, which is then summed. This benchmark is repeated every client restart, but not sooner than 4 days after the previous (IIRC also after each client up/downgrade). The re-benchmarking can be disabled (Read config manual), which I've done as I consider it a waste of time with how I operate. The client is supposed to learn, but given that the noted DCF (duration Correction factor) control has been hobbled, locked to a value of 1, that learning is limited. Beyond that, a task has a header with an estimated FPOPS total which then is used to compute an estimated runtime (TTC or Time To Complete) in amongst using the benchmark. As noted, WCG uses the actual runtimes on many returned results to then stick their average runtime FPOPS into new work headers.

Since there's a time delay between receiving work with a X FPOPS and the actual FPOPS in the reported task, and the feeder build pipe which can be several days deep, not to forget the on-client buffer size, that the FPOPS what's stuck in the new work headers is lagging reality, so we get work that can have an estimated runtime of 3 hours, but then runs 13 hours or vice versa.

Server side there are some 'learning' rules that relate to compounds and proteins targets, but they have to be tech developed.... nothing remotely what one could consider AI. Short for, it will hardly ever be right, subject to change without notice, except for processes such as with MCM which produce pretty stable runtimes.

QED

ROFL

Thank you for that excellent explanation.
I notice that SCC has wildly varying runtimes for different WUs. I guess different batches/science for shorter vs. longer ones?

Also. What, exactly, do quorums do here? I take it if I am quorum number 1 I'm the first machine with this task and my result won't be verified or validated until number 2 gets it and processes? Similarly, if I'm number 2 (or however many, I'm guessing there is only two?) And finally, is this other quorum also called the wingman? I hear this terminology and am just trying to understand a little more.

thanks!

Quorum is an indicator of how many copies need to be cross validated for a task, starting with suffix _0, _1 etc. 'Quorum 1' is really silly, better referred to a Zero Redundant. Since quorum 2 goes to random clients, the time needed to have both come back varies. Very old stats, it takes about 2 days to get 95% validated, then another 2 days to hit the 99%+ mark, and the rest can take 7-10-14 days before a match is found.

Sometimes is a 3rd copy (suffix _2) needed to determine if copy _0 or _1 is valid, if they did not agree.

We are mostly dealing here with Non-Deterministic computing. The target complexity, the molecule size/shape, the energy needed to perform a dock, very much influence how long a calculation can take. Typically in bio, a lowest energy dock has the highest interest, at which point the calculation moves on to the next step, or ends the task or step if a 'wanted minimum lowest energy' is not achieved.

Based on the returned data in the beta and initial project phase, will the techs determine how much work can be packed in a task and not blow the patience fuses in your head.