Obviously you're not an [American] banker. The more debt, the less chance you have with my bank to get more added to the loan.

mitrichr,

Really, with 0.1 buffer and 8 cores you'll rarely have more than 8-12 jobs to start in cache (additional buffer). As I noted, just let it run for a wee while. 0.1 cache is 2.4 hours - per core-. Next set it to for instance 0.25 days (6 hours and the hard coded default) and let it run. Don't get overzealous... let the beast grow slowly. With the number of projects you have attached there's so little chance you not having access to work from somewhere that with a 12 hour cache (0.5 days) and a solid internet connection, there's no need to go higher.

Presently, in your case, 0.1 cache and 8 jobs running concurrent that WILL at times result in 8 jobs running and nothing cached, UNTIL the work in progress has "time to complete" WHICH IS INCLUDED IN THE CALCULATION has a mean run time left of less than 0.1 days.

If not already noted, the -86400 seconds debt, per project, equal one day per project is a limit at which the LTD should stop you from fetching work from that project, so other projects get a chance. The funny is, that by allowing other projects to crunch, that debt is paid off.

Anyway, 6.10.18 is designed to always keep all cores busy. That has to be taken with a small grain of salt. I observed on my duo yesterday that work was fetched only when a job actually had completed, so 1 core idled for 1 minute. That is with a setting of 0.01 day cache. I suspect the job had a sudden fast finish causing this. But work was fetched quickly, the call made within the second from job completion.

Hope I've not confused you.

PS: With certain projects you used to be able to clock up millions of debt. CPDN was/is a good one doing that. As yet, under 6.10.18 I've not seen LTD go bigger than -86400, but I'm right now going to force a hand to see if it will go higher. Got way to much for 1 project in suspend and already it's -59k. Releasing it should jump it in the processing queue given that the very small project weight does not justify the cached work volume.

PS; 6.10.18 benchmarks jobs per project so BOINC knows better what to expect when work is being called from a project. Think that is even at a per-science level, not sure though. What I have observed is that it is not calling large swats of work, rather just a one-two, a few jobs at a time [which with WCG can be anything] and then will call more after assessing the sizes received. The test to observe this is incrementing the cache by a little. That is an advise. Just don't jump from 0.1 to 2.0 or whatever. That will risk you of getting too much if BOINC gets the wrong estimated run times fed. AND, anytime a project is contacted, that first project contacted will try to fill that cache, because projects don't care how much they dump on a client. The more they force into your cache the more you'll be working for them, until the debt blocks them from more work fetching.

edit: the should have read they

mitrichr,

Did you read what I wrote to explain why no work might have been coming? 0.5 days on a I7 with hyperthreading is equal 345600 real computing seconds, but since hyperthreads really only gets 15-20% of CPU gap time, it's really worth about 500,000 seconds wallclock. BOINC in time will increment the DCF because of this and turn the knob down again... and seeing you knobbing the cache up again to counter, the problem is being recreated again. PLEASE let it run and learn.

CPU work fetch priority is for work-requests.


Hmm, probably not, since documentation is always lagging-behind...

Also, the work-request & cpu-scheduler has had various re-writes through the history of BOINC, so even if you finds a FAQ, it's possible it's outdated info, and the recommendation will actually be opposite what's true for v6.10.xx-clients.


Needing to zero is mainly a problem if you're running multiple projects and upgrading from v6.4.x and earlier clients, to v6.6.xx and later clients. Since you're starting "clean", it's no reason to zero anything.