Hi,

Since you're still so many days away from target, you best set the minimum buffer higher [don't know how frequent you look in, but if you do every other day, set it to 3 days], then untick the "if there's no work for..." box (though recommended officially). There's always moments in the day that one or the other science does not have anything in the feeder for your platform/hardware combination, so you'd always see alternate work come through with very low buffers. Should you have a follow up target after HCC, you could also select that in addition. Then you're in control of what your device crunches at any time without worrying the device will run dry.

Crunch On.

Whether 0.1 days or 3.0 days, the frequency of work fetch is the same, and long as Beta is ticked, it's always the first port of call to see if there's testing jobs available. Advantage of a MinB 3.0 and a MaxAB of 0.0 is that the Beta are almost always skipped to the top of the processing queue because of their short deadline, so much so that any other "regular" work with a longer out deadline will be paused to let the Beta ahead, all by itself.

Permit me to insert a on the DCF tangent... I can stretch an argument in as many ways you like too... with <dont_use_dcf> in place at WCG, no variable run time projections for the "Ready to Start", at least with my later 7.0.xx clients. "Assuming" the DCF is correct and stable, the frequency of work fetch is constant, but of course if a task lasts 1 second longer than of course that's not absolute, no matter which client version ;P.

That GPU tasks take priority over CPU tasks beyond the point of possible deadline miss was to me an unfortunate decision. Are GPU tasks more important when someone consciously elects to run a mix of sciences? It's very POV, but I think the prime directive is being flaunted, that work assigned, no matter which resource, has to be finished in time and if not doable, in EDF order.