It depends on how deep you set your buffer. Rule of thumb... keep your Minimum Buffer to -less- than half of the shortest deadline and keep the MaxAB [Max Additional workBuffer] to zero. With that rule applied, the order will be FIFO, first In First Out. As FAH2 is 4 days [always I think], the setting has to be < 2.0 days or they will most always jump the queue and in your case they will always, since the buffer is greater than 4 days anyhow [If you only set FAH2 with that buffer size, you might even incur "will not finish in time"]

Remember with a 2 day buffer, the work started is already 2 days old, so you still might see the occasional EDF [Earliest deadline first], when repair job arrive, who's deadline is, except for FAH2, about 2.8 to 3.5 days for production work. Think also the HST1 is always 10 days, so they will hardly get rush treatment.

BTW the deadline is predicated on the sequence dependencies. Your result is the immediate base for the next task. With a 4 day deadline and 30 dependent tasks in a sequence it means that getting one final result, number _30 to the scientists could take up to 120 days, for the -ls- type even 160, though by observation it seems to take somewhere from 75 to 110 days.

There's another form of domination... whenever having multi-project selection and including FAH2, excluding MCM, hardly anything but FAH2 will come. This is aggravated because FAH2 run 14 hours on my 8 core desktop, UGM not coming at all doing 4 hours if fetched manually and the few OET/Zika not even doing 2, so the contribution ratio is completely out of whack. The old question is still up on going: What's the point of multi-project selection pretty plz?

If you forget you end up with a full buffer and idle cores, buffer so full, not even work from backup is being fetched. The solution was/is nice to control CEP2 and other heavies, but WCG broke the priority distribution for this science, no continuous crunching on restricted cores and still ending up with idle resources. 😵

One thing which would substantially enormously help, not sure if not proposed before, but back when there was uproar over CEP2, techs, knreed if I remember correctly, skunk-worked in the 'how many to assign for CEP2... 1-16, unlimited' within hours, less than a day. In pact with app_config this worked superb. Same could be worked in for the very long running FAH2 (and HSTb maybe too)... really like to get to rid myself of this hunter-gatherer perpetual profile manipulating to share the resource (those with a farm have easy talking ;o))), so techs can you pretty plz set your iron-glad immovable schedule aside for a few hours and proof you can still do quick solution works and make more than a few campers happier.

Greetings,

The weights for projects are as follows on the feeder:

mcm1 - 41.67%
ugm1 - 1.04%
oet1 - 28.13%
fahb - 10.42%
hstb - 1.04%
zika - 12.5%

(I know this does not add up to 100%, we have beta apps as well as some rounding)

So, if you have mcm1 unselected, you may see more from fahb, this is because with shorter tasks from zika and oet1 when someone with that project selected specifically they will pull more results off the feeder at one time. They request 24 hours worth of work, they may pull many results off the feeder. But if they were to try to pull 24 hours for fahb, they may only pull like 4 out of say 40 sitting on the feeder.

There is no plan at the moment to limit the number of results per host for FAHB. The reason that cep2 has that option was due to the high IO for those work units.

As for our immovable schedule, the schedule changes from time to time. There has been an enhancement that I have been working on to potentially fix the download issues for members. Phase 1 of that was deployed yesterday without any members noticing or having issues. We are about to utilize a beta test to test phase 2 for this enhancement. I will explain more then. These are just enhancements that I was working on, others on our team are working hard on other important tasks as well.

Thanks,
-Uplinger