Until recently I've been running only one BOINC project at a time on my computer (BOINC client 5.2.14). Now I'm attached to two projects. The one project has WUs of four to twelve hours; the other has WUs of one hour (but has more data to be downloaded for each WU). I normally run off-line, meaning that when I activate my suspended network connection, there is usually quite a lot of data to be uploaded and downloaded.

I'm on a dial-up line, so the larger downloads (of the data for each WU) take 8 or more minutes each. I was AMUSED to see the behavior of the BOINC client. It is running the WU for the one project. Then a download finishes, making an additional WU "ready". The BOINC client pausses the WU that was running, and runs the WU for the other project. Then a download finishes, making an additional WU "ready". The BOINC client pauses the WU that was running, and resumes the WU for the first project. Then a download finishes, making an additional WU "ready". The BOINC client pauses the WU that was running, and resumes the WU for the second project. Then a download finishes ...

What I am seeing is a "ping-ponging" between the WUs of the two projects, every time a completed download "readies" yet another WU on my not-yet-crunched queue (which I've defined to be several days long). The interval between "ping-pongs" is how long it takes for the next data download (which readies a WU) to complete, __not__ the "time between project switches" as defined at the server website.
.

What I am seeing is a "ping-ponging" between the WUs of the two projects, every time a completed download "readies" yet another WU on my not-yet-crunched queue (which I've defined to be several days long). The interval between "ping-pongs" is how long it takes for the next data download (which readies a WU) to complete, __not__ the "time between project switches" as defined at the server website.

JM7 is perhaps the person to answer this most authoritatively, but I'll try nevertheless.

Which project and which WU to be crunched next gets evaluated due to several reasons. The basic reason is expiry of timer which you set as time between project switches in your preferences. There are other reasons to do that:

• crunching of a WU is finished
  
• file gets uploaded and/or downloaded
  
• there are dozens of reasons but right now I can't remember any of them
  

Regardles of the reason which caused scheduller to re-consider the next WU, the only rule which governs selection is the amount of Short Term Debt: project with the largest STD is entitled to run next.

[edit]
Actually there are other rules, such as that work should be done well before deadline - in this case scheduller starts EDF mode.
[/edit]

It really is annoying to see stopping and resuming WUs every time a file download is finished (eg. a couple of seconds). I started an argument about changing scheduller behaviour in another thread. Perhaps changing behaviour as described in previous post should be one of goals as well?

Perhaps a good solution would be as follows:

• when selection algorythm gets triggered due to expiry of time between project switches, it should work as it works now
  
• when selection algorythm gets triggered due to any other reason, it should continue to run the same WU as it had unless schedulling algorythm decided that it's time for EDF
  

What do you think?

---

Metod ...

Basically any project related action is likely to cause a rescheduling, including but not limited to: task changing to 'ready to run' status, project suspend/resume, project reset, result suspend/resume, and successful scheduler RPC.

---

BOINC WIKI

BOINCing since 2002/12/8