New values from today

Project LTD
superlink -5040
einstein -20145
hydrogen 0
lhc 47388
milkyway -5563
mindmodeling 3140
qmc -3563
seti -7288
cosmology 0
AIS -8927

LTD reset.

Since projects that are in communications deferral are already removed from these calculations, you are potentially double removing them which could lead to a negative total resource share.

Well, I didn't see that as

 
        if (!p->active.size()) {
	    double rsf = trs ? p->resource_share/trs : 1;
            p->cpu_shortfall = work_buf_total() * overall_cpu_frac() * ncpus * rsf;

so there's a shortfall for a suspended project with no work
and a project with no work but which is not suspended has a shorter shortfall (as total_resource_share contains suspended project too).
and it seems to me that there's a link between shortfall and work_request.

Another point, I'm testing,
when a project with no work is getting work, set the STD to a value linked to the share and the LTD. The purpose is to start quickly a project with a big LTD, in order to avoid the increase of it as STD is smaller than some other projects.
Actual LHC case : Small work and then nothing to do for 4 or 5 days.
So in this case, LTD is bigger after the computation than before (when many projects are running).

Yes, there is a link beteen shortfall and work request, however, that is NOT how the work requests are ordered. The project with the highest LTD that is contactable gets first chance. The reason that projects with negative LTD values get a shortfall requested is to avoid having a dry CPU if there is no contactable project with a higher LTD. Calculating the shortfall does not affect which project is contacted for work.

---

BOINC WIKI

Yes, there is a link beteen shortfall and work request, however, that is NOT how the work requests are ordered. The project with the highest LTD that is contactable gets first chance. The reason that projects with negative LTD values get a shortfall requested is to avoid having a dry CPU if there is no contactable project with a higher LTD. Calculating the shortfall does not affect which project is contacted for work.

Yes, I know, this is not the purpose in this case, but the work request is enlarged, as sample, I got 10 projects on a computer, 5 are suspended (total share 250), 3 are running projects (with works - total share 550), and 2 without any works (total share 200), the work requests computed before the change on those 2 projects was near 8000 seconds of work (about 84600 * 100 / 1000), now it is more like 11000 seconds so near 84600 * 100 / 750, so I may have more work if project restart, and I think it is more like my settings (as I suspended those projects, I want the others use this freed cpu time as they were detached).
It works on active projects too, as total_resource_share is lower.

About the other point,

when a project with no work is getting work, set the STD to a value linked to the share and the LTD. The purpose is to start quickly a project with a big LTD, in order to avoid the increase of it as STD is smaller than some other projects.
Actual LHC case : Small work and then nothing to do for 4 or 5 days.
So in this case, LTD is bigger after the computation than before (when many projects are running).

It seems ok, for now, tests on LHC with a STD set to LTD * (runnable) share_frac at restart, this project is now running once download is completed and the cpu_schedule swap task, so its big LTD start to decrease, but I don't know yet, if this setting is correct (depending on LTD, it must not be too large or short and I'm thinking about a limit based on cpu_scheduling_period).