I am still trying to fully understand how the BOINC scheduler works. This is what appeared strange to me lately:

05/07/05 03:06:12|Einstein@Home|Restarting result w1_0175.0__0175.1_0.1_T00_S4hA_1 using einstein version 4.79
05/07/05 03:06:12|SETI@home|Pausing result 29ja04ab.14046.11682.73576.241_0 (removed from memory)
05/07/05 03:06:17||request_reschedule_cpus: process exited
05/07/05 04:06:17|Einstein@Home|Pausing result w1_0175.0__0175.1_0.1_T00_S4hA_1 (removed from memory)
05/07/05 04:06:17|SETI@home|Restarting result 29ja04ab.14046.11682.73576.241_0 using setiathome version 4.18
05/07/05 04:06:18||request_reschedule_cpus: process exited
05/07/05 04:06:32||Suspending work fetch because computer is overcommitted.
05/07/05 04:06:32||Using earliest-deadline-first scheduling because computer is overcommitted.
05/07/05 05:06:19||Allowing work fetch again.
05/07/05 05:06:19||Resuming round-robin CPU scheduling.
05/07/05 05:06:19|Einstein@Home|Restarting result w1_0175.0__0175.1_0.1_T00_S4hA_1 using einstein version 4.79
05/07/05 05:06:19|SETI@home|Pausing result 29ja04ab.14046.11682.73576.241_0 (removed from memory)
05/07/05 05:06:23||request_reschedule_cpus: process exited
05/07/05 06:06:23|Einstein@Home|Pausing result w1_0175.0__0175.1_0.1_T00_S4hA_1 (removed from memory)
05/07/05 06:06:23|SETI@home|Restarting result 29ja04ab.14046.11682.73576.241_0 using setiathome version 4.18

The scheduler switched to EDF mode for almost an hour but continued to process a SETI@home WU despite the fact that there was an Einstein WU with an earlier deadline. As you can see from this screenshot, the SETI WU had a deadline of 18/07/05 and the Einstein WU had a deadline of 08/07/05. Resource shares are 50% for both SETI and Einstein, "Connect to network" preference is set to 0.5 days.

I tried to get something out of John McLeod VII's explanation in the BOINCWiki but I must admit that I don't understand the reasoning in the (seemingly incomplete) sentence "In the above example the CPU will be in Earliest Deadline First because Work Unit B and will process WU A and the B until the situation is resolved" and the concepts of 'required time fraction' and 'cumulative required time fraction' that are used in the example. Hence I'd appreciate it if someone could explain the observed behaviour to me.

---

When it decides it needs to run EDF, it doesn't switch immediately. It will run EDF at the next project switch time. (defined by your preferences)

Okay, thanks for the explanation, Heffed. This sounds logical, even to me. ;)

But wouldn't it make more sense for the scheduler to also check its state only during these switch times? In the reported situation, the change to EDF mode was pointless because at the time it would come into effect, the problematic situation apparently was already resolved.

---

Okay, thanks for the explanation, Heffed. This sounds logical, even to me. ;)

But wouldn't it make more sense for the scheduler to also check its state only during these switch times? In the reported situation, the change to EDF mode was pointless because at the time it would come into effect, the problematic situation apparently was already resolved.

The same code does several checks. Some of them have the dual purpose of turning off downloads and also switching to EDF. Whether or not to fetch work is checked every few seconds - once the CPU enters EDF, the checks are turned off until the next possible process switch to allow the CPU some time to recover from whatever the problem was.

---

BOINC WIKI

When it decides it needs to run EDF, it doesn't switch immediately. It will run EDF at the next project switch time. (defined by your preferences)

There is another reason for this that I didn't see mentioned. If it switches immediately the client may get into a cycle where it is switching modes every few minutes. By letting it finish the current timeslice this churning is normally avoided.

---

BOINC WIKI

BOINCing since 2002/12/8