And to add a bit of emphasis to "I see the consequences of the scheduler's thoughtlessness a lot.":

All systems here have a 0.4 day additional work buffer in order to eliminate the possibility that jobs/tasks get "stale"/approach deadline because they're waiting in queue at my end.

There will always be cases where a cruncher would miss matching his/her variables (settings, preferences, BOINC-controls, and the likes) to the requisites to achieve his/her (specific) objectives. If all processes play by the rules, the matter of high-priority WUs should not add any more to the difficulty of maintaining the said matching. Are all processes playing by the rules? What is the rule-set for high-priority WUs? It is apparent -, and there are a number of testimonies -, that high-prority WUs interrupt on-going WU-execution seemingly without regard of the state/conditions of the WUs they are interrupting -- and yes, as if these high-priority WUs do not have rules to follow, else does not seem to be even aware of what impact they are doing to a cruncher's efforts to match variables with objectives.
;
; andzgridPost#866
;

Albeit I stated at the bottom of my second post here are the actual preference tabs from system 9 for perusal


All systems are configured 'almost' identically (disk space allotments may vary between 50 GB and 100 GB while I tend to tell 12 GB and higher physical memory systems they can use 90% of memory at any time rather than 75%...rather pointless).

System 9 is an i7-2600K while 7 is an i7-980x (thus perception of actual work in queue must account for the power/speed of the systems...a CEP2 task on system 9 completes in approximately 6.5 hours times 7 or 8 cores dependent upon HCC GPU and core usage) while 6 and 8 are slower (a Q9550 and i7-950, respectively).

Is it possible that CEP2 tasks in queue are getting bumped by the download of "higher priority"/closer to deadline CEP2 tasks downloaded when the far easier/faster HCC GPU tasks complete and send a new tasks request to the scheduler???

Development of client scheduling has advanced so much, to include the addition of an on-client ability to restrict the number of concurrent processes of an individual science [app_config.xml], it's really not worth anyone's time in debugging a 6.10.xx issue. Recommend you move your clients to a version 7.0.42 or up. No troubles here with either that or my present 7.0.47 on octo on W7, W8, [7.0.39 on Linux Ubuntu and Fedora.]

Per knreed a very large body of volunteers have already moved to the 7 series [still in internal alpha testing, primarily for code auditing and putting the WCG skin on]. Individuals should not feel restrained in upgrading, it's large organizations that do mass roll-outs and companies that volunteers large device counts that do and is the main reason of the in-depth checking that whatever gets the final seal of approval is going to stand up for a longer period [and does not cause IBM themselves internal issue for tens of thousands of seats... their version goes into their software catalogue].

(The project properties screen may reveal a screwed DCF, but we already know about that from prior reports [I did not comprehend] of TTC's flip-flopping from showing the CPU times and the GPU times [twilyth it was IIRC]).

There's no need to uninstall, install. Just run the 7.0.xx and it takes care of first uninstalling the previous version. Think this is loss-less, which was not the case with the early 7.0.xx clients.

An aside, I've done some over-the-top cache testing up to 10 days with 7.0.45, panic breaking loose, but never seeing more than the number of cores ever to be in waiting to run while High Priority/ EDF state was going. After, set the MinB [Minimum work buffer] to zero and all panic should eventually cease. Just abort the oldest, not yet started work for as much that you know the remaining queued work will complete in time. There's no reason that what has started to be aborted.

BTW, there's definitely no loss-less way back to 6.xx once you've done the 7.0.xx upgrade. AND, there's a draft FAQ explaining old and new buffering. The Additional Buffer has become a type of overflow.... put out a work call and get as much as possible withing cache setting constraints, but if the MaxAB [Maximum Additional Work Buffer] does not get fully stocked, still not not ask for more and wait until MinB has been dropped below it's setting level... this means that if BOINC goes wild, it will only do it one call in your case, since as I understand your MinB [fka Connect about every] is set to zero.