World Community Grid - View Thread - Ridiculous handling of priorities.

I have often noticed that some so called priority wuâs are pushed ahead of the running wu. I would understand moving them up in the Q line but why stop an almost finish wu with only minutes to completion to replace it by a 6 hours run time for a priority wu.

I worked 30 years for IBM and I have seen such stupid management on the production floors. So much that at the end of the day no production is completed on four lots that are placed on shelves all waiting for a break in the schedule.

I would suggest that a priority wu is simply moved up in the Q line. But the currently running wu's is given a chance to finish.

The problem with your suggestion is, even a wu claims it will finish in example 5 minutes time, in reality these 5 minutes ocassionally becomes 5 hours or in extreme cases multiple days. Since the BOINC-client should also handle these extreme instances if at all possible, this to you ridiculous priority-handling has been choosen.

In the beginning the BOINC-client did assume all BOINC-projects did work nicely, but experience has taught us this is not the case so the BOINC-client also tries to handle instances like "oops, typed 8 instead of 3 meaning the wu uses roughly 3x longer time than specified" or "a normal wu calculates for 10000 conformations and normally 1% is 'slow' while 99% is 'fast' calculations but unfortunately you got the one wu in a 1-million-wu-batch there the last 10% was 'slow'". Note, while BOINC-client always has used a max-FLOPS-limit, some projects set this limit so high you won't reach this limit even if wu uses many days longer than estimated.

BTW, in case you're still using one of the v6.10.xx-clients, these clients has some major problems as far as cpu-scheduling goes...