I'm trying to figure something out here. I'm not sure if this is a bug or if I did something wrong.

My computer is running Boinc 7.16.3 with three projects: Einstein, MilkyWay, and Seti. I had been running all three with equal resource shares of 100 for most of January. My computer has 4c/4t, with an AMD APU (Vega 8) and Nvidia GPU (1660 Ti). I had enabled AMD/Nvidia GPU tasks for Seti (with no CPU tasks), and CPU/Nvidia tasks for both Einstein and Milkyway.

To make a long story short, I set Einstein to NNT until it went dry. I then set its resource share to 0, and enabled CPU/AMD/NV tasks. At that point, I had set MW & Seti to NNT. Even though there were plenty of CPU and NV GPU tasks in my queue, I downloaded 200 Einstein tasks for CPU/NV. Yes, I made sure my settings were saved online prior to updating Einstein in the client. Einstein tasks are being processed even though there are still seti/MW tasks downloaded.

My past experience was that if a project had a resource share of 0, it would only download enough tasks to keep a CPU/GPU busy if it was idle. Am I missing something?

I think what happens is that when your system contacts the projects it asks for data before doing anything else.

For example: Your system is in venue "default" and you go to the project and you set resource to 0.0 for venue "school" and select "school" for your system.
The next time your system contacts the project it asks for data and gets a boatload and then is told to switch to "school"
Thereafter, the next time it contacts the project its "school" venue says it can have only 1 work unit but only after finishing all tasks.

This has happened to me more times than I can remember. Suggest let a few tasks finish before aborting them all or you might get on the 24 hour blacklist.

Doesn't have to involve a venue change - that applies to any change to settings made on the project website.

Remember that no project server can unilaterally send you work. It wouldn't get through your firewall. Instead, project servers respond to your computer's request for work.

So for every website change, you have to make TWO project updates. The first transfers the change in settings from the website to your computer: the second acts on the new settings.

If you want to stop something happening,

* Set 'no new tasks'
* Make the change on the website
* Update the project
* Allow new tasks

I see now. Can't the computer update project settings, then request for new work? That seems like a relatively easy fix? Unless that bogs down the servers too much?

All things are possible.
But this is how it is in this reality.

I often change settings between different climate models, and then have to remember to Update to actually get that new setting to the computer.
And then there's a one hour backoff before I can use the new setting.
(Part of the attempts to stop "killer computers" from wasting tasks.)

So for every website change, you have to make TWO project updates. The first transfers the change in settings from the website to your computer: the second acts on the new settings.

I don't agree this is actually what happens all the time, because the server is intelligent enough to know you already have different preferences than what your client is asking for. So if you change for instance that from now on only GPU work can be had, and your client requests work for CPU and GPU, the server will a) send the new GPU only preferences, and b) only give work for the GPU (if available). It may not work this way if you change from asking CPU work to asking GPU work, because then the client asks the first time work for the resource that's set to off on the server.

---

So if you change for instance that from now on only GPU work can be had, and your client requests work for CPU and GPU, the server will a) send the new GPU only preferences, and b) only give work for the GPU (if available).

I'd like to believe that, and it's what the documentation says should happen. But my nasty cynical mind is saying that it hasn't always happened, at all projects, in the past.

That's what I started off with.

I don't agree this is actually what happens all the time,

---

Several things going on at once.
Basic part, computer is asking for tasks. Server has tasks available. Computer has room in the work available for tasks, or it wouldn't have asked. Server has tasks ready to send. Server sends tasks.
The issue is, computer asked for tasks. That item takes priority.
In fact with a zero work share if the computer asks for tasks the server will attempt to fill the work cache. So it doesn't actually matter when the server updates the computer to the zero share. Asking for tasks takes priority.
This is what is at the bottom of what was seen.

Same as when you set CPU resources to '0' (null), it interprets it as 100%, or highest.
Try setting resources to the lowest possible number bar zero, perhaps 1, or a decimal (0.1-0.000001; whatever works out best)

Very different:
In the resource share "0" means "this project is a back-up project, only get a task when there are no tasks available from any of my non-zero resource projects", but in the case of the CPU use "0" means "use the default value (which is 100%)". And yes, it can be a bit confusing as I don't think the use of zero is clearly explained in either case.

Setting a very low resource share for a project will mean that project will get a tiny amount of work, even when there is work available from other projects.