Don't know what the best strategy is to avoid any HP, but it's hard to see how many could build up if the cache is very short combined with a long switch time so tasks complete in 1 run, most of the time which would then work kind of very close to FIFO.

As for running out of memory with LAIM on, I was told, then tested and could confirm that if that happens, BOINC will dump preempted tasks from memory if it starts to run short.

More manual switches which runs contrary to a design goal of "set and forget".

If you are not going to fix this problem please give the option to disable the High priority system so it runs only FIFO.

I'm no 'you' that can fix things. I participate on the alpha mailing list as a volunteer and occasionally insert an interruption of regular service. Some were actually taken on board and led to a fix or implementation to make crunching live better. You could do too.

Kind of a moot discussion since 6.12 has many scheduler changes, also to address the inordinate running of HP, and stop work fetch where needed. Maybe give 6.12.18 a trial and enroll in the alpha mail list to follow the discussion, though I feel it wont stand for long and the next alpha version will be compiled.

--//--

Have you considered reducing the additional work buffer so the computer isn't faced with digesting quite such big dinners in future?

A PITA or not, it is the only way in which you can prove beyond a reasonable doubt that your BOINC isn't doing things according to how it should be doing it, your opinion and screen shots don't do those. It's not so much for me that the logs are for but for the developers. You want them to change BOINC, to fix possible bugs, right? Then you'll have to come with proof they can read.

Yet you refuse to give definite proof, by debug logs.
You won't give any information other than that 'you seen it'.

Or you will, but only after the developers change the program so it does what you want it to do, despite what that does to all the other people out there? Bit of a weird demand.

If you want to change it so it runs as you think it should, get the source code and start hacking at it. It's open source. Should be easy for you to make it do what you want, seeing as how you can tell without a shred of evidence that the system is broken beyond (your) repair. :-)

Have fun. I'll not return here, as you make me laugh too much and that's still too painful. :-(

So if you care to overfill your cache you can see for yourself how boinc doesn't pick the task with the earliest deadline (+/- estimated runtime) first.

Again, run with debug flags to corroborate this claim. In the least <rr_simulation>

Of course, overfilling your cache on purpose... well, what do you expect then?

Sorry, but a statement is only an hypotheses requiring a reproducible proof to become a theory which may eventually be considered as fact.

...Without all of that information your post is just text on a monitor. No developer will be able to do anything with it as there's nothing to compare it with, or no way to reproduce it.

When running at high priority, priority should be given to the unit with the earliest deadline and nothing else (except possibly +/- the estimated runtime). Any other system of selection will only and can only increase the chance of units being returned late.

Imagine you have two tasks on your single-core machine:

• task A was already running 16 days, 5 hours to go and its deadline is in 6 hours.
  
• task B was not running yet, it has 3 hours to go and its deadline is in 4 hours.
  

Should the client crunch task B, report it soon enough, then continue with task A, report it 2 hours past deadline and risk more than 16 days of work being discarded?
Or should it crunch task A, report it soon enough, then possibly either abort the unstarted task B (because it is already past deadline) and ask for a replacement (to be crunched in-time), or (if not yet past deadline) crunch the task B, report it and risk 3 hours of work being discarded?

The decision is not always that simple, like your imperative "earliest deadline and nothing else"...

Peter

except possibly +/- the estimated runtime