Work Buffer
From Unofficial BOINC Wiki
Contents |
[edit] General
The list of Work Units that have been downloaded to the Participant's Computer and are awaiting their turn to be processed. All that the Work Buffer is doing is to queue Work Units until they can be processed by the Participant's Computer.
[edit] Work Buffer Size
The size of the Work Buffer is set in the General Preferences as the setting "Connect to network about every 'x' days".
This setting is the control for telling the BOINC Manager how much information should be kept within the Work Buffer. In essence you are setting a Low Watermark to control the amount of work that the BOINC Manager will maintain locally to ensure that the BOINC Manager will never run out of things to do. In the "bad old days" we had to watch our processing and then determine through "guess-work" how many Work Units we would maintain in a queue to make sure we could always keep SETI@Home Classic busy. In my case, I kept about 4 days supply to cover those remote possibilities where a series of problems prevented me from contacting the Data Servers because of problems on either end of the system. The worst part of it was that this was a guess of how much work to keep on hand. Now, since the BOINC Client Software knows how fast you are likely to complete work, you can set the schedule in full and partial days of how much work to keep on hand, and how wide the spread should be.
Our recommendation if you use a dial-up connection is to keep about 2 to 4 days divided by the number of Attached Projects of work on hand. I mean, this is a pretty good range of days, and will give the your BOINC Client Software a reasonable set of values to present to the Scheduling Server(s). You don't want to get so much work that you keep having Work Units going "stale" because you don't complete them until after the Deadline has passed. On the other hand, you don't want to let it get too low either, because then a one day outage might cause problems. The other item of good news is that with multiple project capability, the BOINC Client Software can, and will, contact other Attached Projects if it cannot get work from one Project, it will select another Project and continue on. So, this feature in the BOINC Client Software will ensure that a significant disruption of one project's ability to give out new work and take in old work will not cause that "Idle" CPU Time to be "wasted". Of course, I was presupposing that you will have multiple Projects in your list of things to do.
This setting does, indirectly, control the amount of disk space that will be used by the BOINC Manager for storage of work to be processed by the Science Applications. This should not be a big factor in controlling this, I am merely pointing out that the storage of Work Units locally in the Work Buffer will consume disk space. And since this setting tells the BOINC Client Software how much work it should keep locally, it does impact on the amount of disk space consumed.
Choosing the amount of work that will be retained in the buffer is dependent on a lot of things:
- Speed of the Central Processing Unit (CPU).
- Settings on when, and how often to contact the Project(s).
- Availability of work from the Project(s).
- The number of Projects to which the BOINC Client Software on this computer has been attached.
- The Resource Share levels.
- The "Deadline" for the return of the Results calculated for the Work Unit.
- Phases of he moon.
[edit] Recommended Work Buffer Size
This is one of those "it depends" settings. In general, I would not try to keep too much work queued up. The more Projects you are attached to the lower this should be. If you have unreliable connection to the Internet, then I would recommend higher settings. By the way, partial day settings are possible. So you can make a setting for 2.5 days and it will give you work for 36 hours, so if you want a finer granularity on your Work Buffer you can use fractional numbers.
The projects will be contacted in an order that is driven by a number of factors, including:
Because of the complexities, we are not going to offer more details here, but suggest that you read the material in the Glossary for those terms.
The only items that you need to take into account when determining the maximum buffer (cache) size that you should specify are the shortest Deadline on any of the Projects that you are attached to, and the processing time on your slowest machine that will use this setting (this Venue) so that it will complete a Work Unit before that Deadline for that Project. For SETI@Home the minimum deadline is about 4 days, and for Predictor@Home the deadline has been one (1) day to one (1) week, depending on the Work Unit. From this you need to subtract the processing time for one Work Unit on that system, as the buffer will overfill by the processing time for 1 Work Unit minus one second. For example if you crunch only for SETI@Home, and you set your queue to 14 days, the last Work Unit in the queue has no chance of finishing before the deadline if the processing estimates are, on average, correct.
Now, as for the actual Work Buffer size that you set, you should factor in your connection and your machine reliability as well. If you have an elderly machine that you are expecting to die last month, you might want to keep a short queue until it does so (I have 4 of these crunching away for me). If, on the other hand, you are sometimes connected (dial-up or traveling or untrusting of connection attempts through your high-speed connection), you might wish to keep more work on hand than the duration between your connections. The queue size was left up to the participants, because one size fits no one (or does not fit all, depending on your mood). One of the Participants that I know even has to take his machine to a friends house occasionally to connect to the Internet at all, I believe he said once a month. Once a month is too long for SETI@Home Powered by BOINC, and he is going to have to find a more frequent connection, but the scenario does exist.
[edit] Recommendation for Single Project Systems
A new work-request scheduler was introduced in v5.8.xx, using:
Computational deadline = report deadline - (Work Buffer size + 1 day + "switch between projects every N hours")
A Task is in deadline trouble if Computational deadline < 0.9 * report deadline
A Project even if only one task is in deadline trouble, is blocked from asking for work until not in deadline trouble any longer, or, atleast 1 cpu is out of work.
v5.10.xx did one change, it removed the "1 day"-safety-margin. This means cache-size can be set higher in v5.10.xx and later clients.
Setting Work Buffer larger than in the table for a specific deadline will actually give less cached work
| Deadline (days) | v5.8.xx - Max cache size (days) | v5.10.xx - Max cache size (days) |
|---|---|---|
| 2 | 0.45 | 0.92 |
| 3 | 0.92 | 1.40 |
| 4 | 1.40 | 1.87 |
| 5 | 1.87 | 2.34 |
| 6 | 2.34 | 2.82 |
| 7 | 2.82 | 3.29 |
| 8 | 3.29 | 3.76 |
| 9 | 3.76 | 4.24 |
| 10 | 4.24 | 4.71 |
| 11 | 4.71 | 5.19 |
| 12 | 5.19 | 5.66 |
| 13 | 5.66 | 6.13 |
| 14 | 6.13 | 6.61 |
Max cache size depends on "switch between projects every N hours", table uses default 1 hour.
[edit] Recommendation for Multiple Project Systems
If you are running several BOINC Powered Projects on a computer we suggest a maximum value of 2 to 4 days divided by the number of Attached Projects if you use a dial-up connection. If you have an always on Internet connection we suggest a setting of 0.1 days (2.4 hours).
