I do know that his has been working on a new version of the website for about 18 months and the new site is expected to go live around the end of this month

The minimum work buffer setting sets the minimum amount of work you're going to request.
The maximum additional work buffer sets the additional days worth of work you want to have.

Not quite. The meaning of the prefs is:
- The client requests work for a given resource when the amount of buffered work falls below min.
- It requests (from the highest-priority project) enough work to bring the amount up to min + additional.

What you do forget here is that there are scientists behind all the projects who expect results back.

Malariacontrol has a deadline of 3 days. Not much and it may make BOINC go into high priority even when you've been attached to that project for more than a year

What is it with the overwhelming need to tell BOINC what to work on next?

Why are you running BOINC, to help the science or to gain all those credits? Does it then matter where you get them from?

Is someone forcing you to stay with the project(s) that in your eyes do things so damn wrong?

It's set to a connect to of 0.1 days and cache of 0.5 days. Furthermore, BOINC only runs between the hours of 9pm and 7am when electricity is cheap (5pm and 7am in weekends). It will suspend all work when I start games

I have yet to see any project's tasks run in high-priority.

You are forgetting that you have set project resource shares. Yes, Lattice is getting extra time now but eventually BOINC will not download more Lattice tasks and then your other projects will be paid back the time Lattice took from them. Therefore it doesn't matter if Lattice gets extra time now. What matters is what happens over the longterm and over the longterm your project shares will be honored.

If you do not look in BOINC all the time, then how do you know you get high-priority work all the time (as you claim to have in that same post)?

When you see BOINC run your work in high-priority all the time, either:
- you're seen as a high-value user with very much trusted computers by the project who send you work with a very short deadline;
- or you've got too large a cache for all the projects you're attached to;

- or you just added a project that BOINC hasn't a clue how long the tasks run for, whose estimate is way way way off and for which BOINC has to run some tasks to get a feel of how long these tasks run.

- or you've got too much work from one project whose deadline is very short;

I think in theory the high priority function can suspend tasks and switch to others resulting that none of the tasks are finished before the deadline.

If that ever happens then you have valid reason to complain. At that point the suggestion will be to decrease your cache. In all the years I have being using BOINC I have never had a task miss a deadline. There are 2 reasons for that

Please, think outside your own box. It's built in for ... people who were complaining that despite BOINC's applications running on the lowest possible priority, it taking up CPU cycles that would slow down their computer.

You can use the <exclusive_app> and <exclusive_gpu_app> functions of BOINC for suspending BOINC when it detects any of the games entering Windows memory.

Thanks for telling me where I needed to make changes for the suspend computation, since that part seems to be awfully twitchy.

So I just changed that value to 0. Works just like it used to know.

The way that debt is calculated changed between BOINC 5 and BOINC 6.6, so you would have to reset all projects after you update to 6.6 to get a more correct view on things.

• I was able to retrieve and re-install a 5.10.45 x86_64 client. Once done, everything went fine because this client has resetted the CT/LT balances to acceptable values. Each project was now requesting an amount of seconds of work AND GET JOB! This client don't handle GPU, no matter.
  
• Now let's install the 6.6.38 x86_64 client over the 5.10.45. It starts to ask for GPU job for each project, but no more CPU job is asked. After 24h of working, no more job AT ALL is downloaded, only the remaining tasks previously downloaded compute with alternance.
  
• Let's install the 6.10.24 x86_64 last client over the 6.6.38. It doesn't change anything: no more job asked, no more job got.
  

Let's erase all client binaries and config files, but always keep projects file.

• Let's install again the 5.10.45 x86_64. Same pattern: Each project is now requesting an amount of seconds of work AND GET JOB! (Edges, Malaria, Ibercivis, WCG, etc, have always some jobs to compute)
  
• Let's install the 6.10.24 over the 5.10.45. After 24h, the client is still asking and getting jobs.
  

May be, I step too fast into conclusion, but it seems that there is something really wrong in the 6.6.x trunk which corrupt the config files. The next client generation being not able to correct this and follows the previous config files corruption.

This is corroborated on the others Windows hosts. Too of them were upgraded directly from 5.10.x to 6.10.24, these ones ask and receive jobs. The another one from 6.6.36 to 6.10.24, this last one only ask for GPU jobs.

In order to be very precise: only one of my windows hosts is running 24/24h. The three other ones describe above are shutdown many times a day. I don't know if this is revelant, but I may guess that the scheduler could be more "in pain" running 24/24h, than running a few hours and being resetted by a shutdown.

Exception which confirms the rule: 6.6.36 Linux (Mandriva) client has no scheduler problem at all and receives well jobs 24/24h 7/7d, but hasn't any CUDA/ATI graphic controler.

To be continued!

In the meantime, be assured that current BOINC clients will indeed keep all your CPU cores busy

You'll have to contact the projects about this behaviour.

Your plan on using boinc_project is a no-go, as that userID is only used when BOINC is installed as a service.

Since you are using a service installation, you could write a batch file that closes BOINC every so often