I'm having a trouble with the last 5.8.8 scheduler.

- I've set a work buffer of 7.5 days in the general preferences, to do along run on SIMAP;
- I've suspended every other project on my pc (Suspended & No new task);
- I've done a reset to the long term debts;
- SIMAP has a resource share of 1000 and every other project has a resource share of 1;
- I don't have any other project's WUs in the cache.

In spite of all this... there is no way to get more work even if my work queue is shorter than setted by preferences: at the moment I've 72 WUs (2h each), but running two task at once with my P4 HTed, in 72h I can finish them, so in 3 days... Where are the other 4.5 days of cache? Why the BOINC Manager doesn't ask for more work?

Let's add some details: I don't have problems with disk space, I didn't reach the "Maximum daily WU quota per CPU", there is work available on SIMAP, my pc is not overcommitted and I don't have the global_preferences_override.xml in use. Furthermore, these are my activity parameters from client_state.xml:
<on_frac>0.792576</on_frac>
<active_frac>0.997625</active_frac>
<cpu_efficiency>0.978744</cpu_efficiency>
So even if my pc is on only 19h/24, I should arrive to 7.5 * 0.792576 * 0.997625 * 0.978744 = 5.8 days... but I'm stopped at 3 days!

I know that, in the new version 5.8.8, work fetching policies are changed, but I can't figure out what's happening! What can I do to obtain a bit of new work?

Any help is appreciated!
Thanks a lot!
Luca B. from Italy

Are you sure it's not *asking* for more work? Maybe it's the server not sending any to the client's request. Select SIMAP on the project list, click Update, and once it finishes the scheduler request, copy the last piece of log here.

Unfortunately, this is not the case! :-(
These are the messages you asked:

06/02/2007 2.10.35|boincsimap|Sending scheduler request: Requested by user
06/02/2007 2.10.35|boincsimap|(not requesting new work or reporting completed tasks)
06/02/2007 2.10.40|boincsimap|Scheduler RPC succeeded [server version 505]
06/02/2007 2.10.40|boincsimap|Deferring communication for 7 sec
06/02/2007 2.10.40|boincsimap|Reason: requested by project

As you can see it's my lazy & guilty Manager :-)
And, unfortunately again, I've got two other PC in this situation. D'oh!!

Re-check debts, maybe they went down for SIMAP again after downloading work. Also, set SIMAP to something like LTD 10000 instead of resetting all to 0.

I've tried that road too.
I stopped the client, manually changed the LTDs and this was my LTDs situation (red by Debt Viewer):

PRJ: BOINCSIMAP STD: 0.000000 LTD: 100000.000000 RSRC: 1000
PRJ: EINSTEIN@H STD: 0.000000 LTD: -100000.000000 RSRC: 1
PRJ: LHCATHOME STD: 0.000000 LTD: 0.000000 RSRC: 1
PRJ: SPINHENGE@ STD: 0.000000 LTD: 0.000000 RSRC: 1
PRJ: UFLUIDS STD: 0.000000 LTD: 0.000000 RSRC: 1

I've restarted the client, I've manually updated... No effects!

I've used the new cc_config.xml with a bit of debug option and this is the outcome:

06/02/2007 3.02.23||[cpu_sched_debug] Request CPU reschedule: Core client configuration
06/02/2007 3.02.23||[work_fetch_debug] Request work fetch: Core client configuration
06/02/2007 3.02.23||[cpu_sched_debug] schedule_cpus(): start
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] Project has 62 projected deadline misses
06/02/2007 3.02.23||[cpu_sched_debug] CPU efficiency old 0.955769 new 0.955806 wall 98.343750 CPU 97.156250 w 0.998862 e 0.987925
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project boincsimap: STD 0.000000, LTD 100000.000000
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project Einstein@Home: STD 0.000000, LTD -100000.000000
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project lhcathome: STD 0.000000, LTD 0.000000
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project SETI@home: STD 0.000000, LTD 0.000000
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project Spinhenge@home: STD 0.000000, LTD 0.000000
06/02/2007 3.02.23||[debt_debug] adjust_debts(): project uFluids: STD 0.000000, LTD 0.000000
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] earliest deadline: 1171108138.000000 70201009.015868_0
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] scheduling (deadline) 70201009.015868_0
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] earliest deadline: 1171108138.000000 70201009.015592_1
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] scheduling (deadline) 70201009.015592_1
06/02/2007 3.02.23||[cpu_sched_debug] Request enforce CPU schedule: schedule_cpus
06/02/2007 3.02.23||[cpu_sched_debug] enforce_schedule(): start
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] want to run: 70201009.015868_0
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] want to run: 70201009.015592_1
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] processing 70201009.015868_0
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] 70201009.015868_0 is already running
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] processing 70201009.015592_1
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] 70201009.015592_1 is already running
06/02/2007 3.02.23||[cpu_sched_debug] finished preempt loop, nrunning 2
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] 70201009.015868_0 state 2 next 2
06/02/2007 3.02.23|boincsimap|[cpu_sched_debug] 70201009.015592_1 state 2 next 2
06/02/2007 3.02.23||[cpu_sched_debug] enforce_schedule: end
06/02/2007 3.02.23||[work_fetch_debug] compute_work_requests(): start
06/02/2007 3.02.23||[work_fetch_debug] compute_work_requests(): cpu_shortfall 608421.810224, overall urgency Need
06/02/2007 3.02.23|boincsimap|[work_fetch_debug] project has 62 deadline misses
06/02/2007 3.02.23|Einstein@Home|[work_fetch_debug] work fetch: project not contactable
06/02/2007 3.02.23|lhcathome|[work_fetch_debug] work fetch: project not contactable
06/02/2007 3.02.23|SETI@home|[work_fetch_debug] work fetch: project not contactable
06/02/2007 3.02.23|Spinhenge@home|[work_fetch_debug] work fetch: project not contactable
06/02/2007 3.02.23|uFluids|[work_fetch_debug] work fetch: project not contactable

Obviously, due to the deadline misses, the Manager doesn't ask for more work!
But now the question is... Why does he detect 62 deadline misses? WUs will miss the deadline if not returned within 10/02/2007... 4 full days... so within the calculation made on the first post!

Any idea?
See you tomorrow... it's time to sleep...

---

I can give you the formula, but I'm not sure how to plug the numbers into it.

5.8 uses only one criteria. If the task will not complete by round robin simulation in < 90% of the time to the computation deadline it is in deadline trouble. The computation deadline is the report deadline - (min_queue + project switch interval + 1 day).

(from here)

---

Kathryn :o)

Let's add some details: [...] my pc is not overcommitted and I don't have the global_preferences_override.xml in use.

Obviously, due to the deadline misses, the Manager doesn't ask for more work!
But now the question is... Why does he detect 62 deadline misses? WUs will miss the deadline if not returned within 10/02/2007... 4 full days... so within the calculation made on the first post!

BOINC doesn't say anymore "Entering earliest-deadline-first mode because computer is overcommitted" or similar, because EDF mode is gone. There is a new system to avoid deadline miss. So how do you know if it is overcommitted or not? There isn't a message for it anymore.

Now, it seems enabling [cpu_sched_debug] does show messages related to that. So there you go, "Project has 62 projected deadline misses", your computer is overcommitted; according to the new way to calculate that.

According to the formula Kathryn posted, it adds some extra values. It decrements the deadline by min_queue (I don't know what it is), by the project switch interval (default 60 minutes, configurable via web), and by 1 day. So if the deadline is in 4 days, BOINC will "imagine" the deadline is in 2 days 23 hours (still have to figure out what min_queue is, so would be even less), and calculate if it would meet that.

That's my understanding of it, I could be completely wrong :)

Thanks for your replies, guys!
This scheduler is still a mistery for me! That's why...

I've got another P4 3.0GHz HTed, in the same condition of the first one. This is a shot of its current cache:


Only 18 WUs! And what does the scheduler says?
2/6/2007 10:46:39 AM||[work_fetch_debug] Request work fetch: timer
2/6/2007 10:46:39 AM||[work_fetch_debug] compute_work_requests(): start
2/6/2007 10:46:39 AM||[cpu_sched_debug] CPU efficiency old 0.996912 new 0.996898 wall 120.250000 CPU 118.703125 w 0.998609 e 0.987136
2/6/2007 10:46:39 AM||[debt_debug] adjust_debts(): project boincsimap: STD 0.000000, LTD 71273.076143
2/6/2007 10:46:39 AM||[debt_debug] adjust_debts(): project Einstein@Home: STD 0.000000, LTD 0.000000
2/6/2007 10:46:39 AM||[debt_debug] adjust_debts(): project lhcathome: STD 0.000000, LTD 0.000000
2/6/2007 10:46:39 AM||[debt_debug] adjust_debts(): project Spinhenge@home: STD 0.000000, LTD -71273.076143
2/6/2007 10:46:39 AM||[debt_debug] adjust_debts(): project uFluids: STD 0.000000, LTD 0.000000
2/6/2007 10:46:39 AM||[work_fetch_debug] compute_work_requests(): cpu_shortfall 1067398.264524, overall urgency Need
2/6/2007 10:46:39 AM|boincsimap|[work_fetch_debug] project has 18 deadline misses
2/6/2007 10:46:39 AM|Einstein@Home|[work_fetch_debug] work fetch: project not contactable
2/6/2007 10:46:39 AM|lhcathome|[work_fetch_debug] work fetch: project not contactable
2/6/2007 10:46:39 AM|Spinhenge@home|[work_fetch_debug] work fetch: project not contactable
2/6/2007 10:46:39 AM|uFluids|[work_fetch_debug] work fetch: project not contactable

IMHO, every task will be completed within midnight (to stay relaxed!), so easily contained withind the deadline.

Instead the scheduler detects 18 deadline misses, so EVERY WUs is, in its opinion, at risk to miss the deadline. I can't figure out how is it possible! I don't know which numebers it uses or what kind of calculation it does...

The only thing I know is that I didn't cheat to get these 18 WUs, but the scheduler of version 5.4.11 decided to get them. Then I installed the new version and now the PC is overcommitted! Ok, now the criteria are more strict than before... or maybe the new version need some time to understand how things goes... Anyway... I'm still puzzled!

---

Ok, I've tried to take a look at the formula. The original post from John McLeod VII says:
The determination of when a task is in deadline trouble has also changed. [...] 5.8 uses only one criteria. If the task will not complete by round robin simulation in < 90% of the time to the computation deadline it is in deadline trouble. The computation deadline is the report deadline - (min_queue + project switch interval + 1 day).

Now, I've setted a Work Buffer of 7.0 days (min_queue param.), my "Switch between applications every" is 30 minutes (30/60/24 = 0.0208 days) and SIMAP gives WUs with a 8.0 deadlines. With the old client there was nothing wrong with that and I've never missed a deadline.

Instead, using the new formula, it's impossible to not overcommit the pc! Why? It's simple: the formula becomes 8.0 - (7.0 + 0.0208 + 1.0) = 8.0 - 8.0208 = -0.0208! So I have no time to complete even only one result. And this is exactly what my BOINC Manager says!

So, if you set your work buffer to 7.0 days and the projects has a deadline of 8.0 days... you have no chance to get new work... It must be something wrong... Don't you think? Now it seems to me that the only way to get more work... is to reduce the work buffer... Straightforward, isn't it? :-) I'm still even more puzzled!

---

I've reduced the work buffer at 2.0 days and it worked!

My first pc (56Wus in cache) replied:
06/02/2007 13.06.21|boincsimap|Sending scheduler request: Requested by user
06/02/2007 13.06.21|boincsimap|(not requesting new work or reporting completed tasks)
06/02/2007 13.06.26|boincsimap|Scheduler RPC succeeded [server version 505]
06/02/2007 13.06.26||General prefs: from boincsimap (last modified 2007-02-06 13:06:05)
06/02/2007 13.06.26||Host location: none
06/02/2007 13.06.26||General prefs: using your defaults
06/02/2007 13.06.26||[work_fetch_debug] Request work fetch: Prefs update
06/02/2007 13.06.26|boincsimap|Deferring communication for 7 sec
06/02/2007 13.06.26|boincsimap|Reason: requested by project
06/02/2007 13.06.26||[work_fetch_debug] Request work fetch: RPC complete
06/02/2007 13.06.26||[work_fetch_debug] compute_work_requests(): start
06/02/2007 13.06.26||[work_fetch_debug] compute_work_requests(): cpu_shortfall 0.000000, overall urgency Don't need
It didn't get new work but exited from the Urgency status.

My second pc (just 18WUs in cache) got about 20 new WUs and replied:
2/6/2007 1:15:25 PM||[work_fetch_debug] Request work fetch: timer
2/6/2007 1:15:25 PM||[work_fetch_debug] compute_work_requests(): start
2/6/2007 1:15:25 PM||[cpu_sched_debug] CPU efficiency old 0.996921 new 0.996908 wall 51.093750 CPU 49.828125 w 0.999409 e 0.975229
2/6/2007 1:15:25 PM||[work_fetch_debug] compute_work_requests(): cpu_shortfall 0.000000, overall urgency OK
So, even in this case no more Urgency!

Now that every PC is in "safe mode", I still have a question: What can I do to set up a big cache (for vacancy reasons, for example)?

Thanks again!

---

The scheduler code has been drastically changed from 5.4.11 to 5.8.8 as you can see from John's post over at Seti.

As far as I can tell, the only thing you can do is play around with it until you find the connect to interval that gives you the maximum amount of work without the scheduler thinking you'll miss deadlines.

Other things go into the decision making too. Your time stats and duration correction factor and debts.

So if one of those things are funky, then you'll get seemingly strange results from the scheduler. But it can only make its decisions on the information it gets.

I won't even being to pretend that I understand how the scheduler works. I have an always on connection and I keep an extremely small connect to interval (.01 days) and run at least a couple projects, so the last time I got into deadline trouble was way back with 5.4.11 when short deadlines at Chess960 would push me into EDF (and then I wasn't in deadline trouble as the WUs only took a few minutes to run) and I've never run out of work.

---

Kathryn :o)

Hmm that seems not to make sense. Probably makes sense, but doesn't seem to ;) Bigger cache, and you get less work!

This scheduler is still a mistery for me! That's why...

There are few people who understand it...

Kathryn, I agree with you in one point... the scheduler works on a base of numbers: if numbers are right, everything is fine; if even a sigle number is wrong, the whole result could be a disaster.

Guided by this idea I wrote my first post! I run application for BOINC since January 2006 and I'm a Seti@Home user since 2000. So I think to have a good experience on distribuited computing. And i'm taking my degree in Computer Science, so I think to know how PCs works with developpers, debuggers, linkers and so on. Before to open this thread I've tried everything I knew to solve the problem and I've made every effort to have the "right numbers", to ease my BOINC Manager's life.

I'm not saying that the Manager is bugged. Now that I know how the new scheduler works (I hope), I say ok, its formula said "no" and it has made the right decision... no new work!

But, IMHO, something is wrong with the formula. With 5.4.11 you ask more work by specifying a bigger work buffer. My experiences with 5.8.8 say: if you want more works... reduce your work buffer!

What comes out from this story is that, even if you do your best efforts, you can't have a big cache (especially if the time allowed, 8days, is near to your work buffer setting, 7days)! Maybe cases like this were left out of consideration at the moment of the scheduler's analisys. Or maybe they were not taken into account 'cause the scheduler is not intended to work with this target.

---

Hmm that seems not to make sense. Probably makes sense, but doesn't seem to ;) Bigger cache, and you get less work!

This scheduler is still a mistery for me! That's why...

There are few people who understand it...

Basic requirement is that work will get done and reported before deadline. You (as in: machine operator) may know that your machine has internet connectivity 24/7, but BOINC doesn't. Hence setting: connect every which has to be read verbatim.

In Luca's case BOINC CC has instruction that in worst case, it'll have possibility to connect project server after 7 days. There's a safety margin of 1 day (just to be on the safe side), etc ...

Reverting John's formula (while keeping in mind that John's formula has to evaluate positively in order to allow new work fetch) to

report deadline - (project switch interval + 1 day) > min_queue

one can calculate optimum value of connect every for Luca's project of preference to roughly 6.97 days.

Another example would be Einstein@Home with 14-day deadlines and 4 hour project switch interval: 12.83 days.

One can not really avoid possibility of getting into deadline problems with variable-deadline projects such as SETI@Home unless connect every is set well below something like 3 days ...

---

Metod ...

Reverting John's formula (while keeping in mind that John's formula has to evaluate positively in order to allow new work fetch) to

report deadline - (project switch interval + 1 day) > min_queue

one can calculate optimum value of connect every for Luca's project of preference to roughly 6.97 days.

This is a very interesting thing, Metod.
Thanks to point it out!

But I've got to reduce day-by-day my cache setting until I reach 2.0 days to collect a little bunch of new WUs.

Now I've setted to "No New Work" to empty my cache and clear my BOINC folder.
Then, after a new installation on every single machine and a new client_state.xml, I'll set my work buffer to find the best parameter.

---

If you have the feeling that your client is wrong, you can increase the amount of requested work by adding a work_request_factor to your client configuration.
http://boinc.berkeley.edu/client_msgs.php

---

If you have the feeling that your client is wrong, you can increase the amount of requested work by adding a work_request_factor to your client configuration.
http://boinc.berkeley.edu/client_msgs.php

I've seen that option... but it's impossible to tweak the scheduler, by debug options, on every moment, on a bunch of different systems!
Sorry, but... someone gave us a new scheduler... I'm only asking that the scheduler could work in the right way!

---

OK, the primary goal is to not report work late. The goal of keeping the CPU busy is of much lower priority. therefore, the CPU scheduler is working correctly as designed. Work has to be finished before the connection before it is actually due. This might be as long as connect every X before the report deadline. The scheduler also to ensure that the task is not actually processing at the time of the connection - hence the slop factors of one day and project switch interval. the rr simulator also takes into account the estimated processing time remaining on all tasks.

It is only projects that have a task that is in deadline trouble that are barred from downloading work. If you are attached to several projects and there are some projects that are not in deadline trouble, those projects will fetch work until the queue is filled or they have a task in deadline trouble.

As was stated earlier, the computation deadline for all work is: Report deadline - (connect every + project switch time + 1 day). If you are really disconnected most of the time, this is required in order to ensure that the report is made on time. If you are really disconnected for most of the time, projects with short deadlines may not be appropriate. If you are really connected all of the time, then a short queue is probably sufficient.

3 days of work + 3 days of disconnected + 1 day + 1 hour > 7 days. You ought to be able to use a 3 day queue for a project with an 8 day deadline. But not a 4 day queue (4 days of work + 4 days of disconnected + 1 day + 1 hour > 9 days). Work fetch and the CPU scheduler have to assume that the worst case can happen - i.e. there will be a connect every X days gap in the connection for the entire period specified by X prior to the report deadline so the work has to be completed before that.

The notice that a project has N deadline misses is an indication that the host is entering EDF mode for N CPUs for that project. If you get the same notice for more than one project, then sum all of the numbers to get the number of CPUs that are being dedicated to EDF.

---

BOINC WIKI

Excellent! Good job, John McLeod VII!

Now everything is clear and my doubts are confirmed.
With some particular combination between cache & deadline, you can't reach the desidered cache. And the main reason is because "Connect to network every X days" is not a cache, but it's, obviously & exactly a parameter about connection!

This is a good strategy for the daily use, but maybe could bring some problems in special event. Here I make two example:

1) Server failures: usually I keep a 3-5 days of cache to avoid problems due to server failures. Having a big cache you have a lot of work and you can wait the server's recovery, without worring about empty cache. Obviously you can avoid this problem working on two or more projects.

2) Vacations and no network available: usually I use BOINC even on my notebook that share my desktop PC's connection. But sometimes I used to fill 7 days of cache to have work even on a trip without Internet connection. When I returned home, my notebook was full of results to report (within deadline) to the projects. Unfortunately, this problem is not resolved by joining more than a project, right?

Now, using your formula, you can have:
about 3 days of cache on projects with 7 days of deadline;
about 4 days of cache on projects with 9 days of deadline;
about 5 days of cache on projects with 11 days of deadline;
about 6 days of cache on projects with 13 days of deadline;
about 7 days of cache on projects with 15 days of deadline;
about 8 days of cache on projects with 17 days of deadline;
about 9 days of cache on projects with 19 days of deadline;
about 10 days of cache on projects with 21 days or more of deadline.

So the upper limit for the cache is no more in the hands of the user but it's controlled by the project's deadline.

Do you think that it will be possible to have two different parameters in the preferences to set cache AND network connections? In this ways we could have a big cache even with a 24/7 connection and we could be free to take our decisions!

Thanks again!
Luca B.

---