Support for negative <work_buf_additional_days>

[Pepo]

I'd like to suggest a support for negative <work_buf_additional_days> in global preferences, with meaning "cache by that many days less work", because "during the specified w_b_min_days off-line period, the computers will be possibly not crunching for (-additional_days) long".

As the work_buf_additional_days value is used solely for calculating the amount of work to be fetched, its negative value does not break current client logic, as long as work_buf_additional_days is at least a bit larger than work_buf_min_days (for a non-negative amount of work to be kept during the work_buf_additional_days time interval.

I've tested following patch on 5.1.45 for the idea (usage of the mentioned variables seems to be identical in the 6.1.x trunk):

Index: C:/Work/Peter/Other/Proj/Boinc/SVN/5_10_45/lib/prefs.C
===================================================================
--- C:/Work/Peter/Other/Proj/Boinc/SVN/5_10_45/lib/prefs.C	(revision 15010)
+++ C:/Work/Peter/Other/Proj/Boinc/SVN/5_10_45/lib/prefs.C	(working copy)
@@ -413,11 +413,15 @@
         if (!is_tag) continue;
         if (!strcmp(tag, "global_preferences")) continue;
         if (!strcmp(tag, "/global_preferences")) {
+            if (work_buf_additional_days < -work_buf_min_days)
+                work_buf_additional_days = -work_buf_min_days+0.00001;
             return 0;
         }
         if (in_venue) {
             if (!strcmp(tag, "/venue")) {
                 if (in_correct_venue) {
+                    if (work_buf_additional_days < -work_buf_min_days)
+                        work_buf_additional_days = -work_buf_min_days+0.00001;
                     return 0;
                 } else {
                     in_venue = false;
@@ -502,10 +506,13 @@
         if (xp.parse_double(tag, "work_buf_min_days", work_buf_min_days)) {
             if (work_buf_min_days < 0.00001) work_buf_min_days = 0.00001;
             mask.work_buf_min_days = true;
+            if (mask.work_buf_additional_days)
+                if (work_buf_additional_days < -work_buf_min_days)  work_buf_additional_days = -work_buf_min_days+0.00001;
             continue;
         }
         if (xp.parse_double(tag, "work_buf_additional_days", work_buf_additional_days)) {
-            if (work_buf_additional_days < 0) work_buf_additional_days = 0;
+            if (mask.work_buf_min_days)
+                if (work_buf_additional_days < -work_buf_min_days)  work_buf_additional_days = -work_buf_min_days+0.00001;
             mask.work_buf_additional_days = true;
             continue;
         }

Initially, to let the idea work, it was enough allowing negative values for work_buf_additional_days with following patch:

         if (xp.parse_double(tag, "work_buf_additional_days", work_buf_additional_days)) {
-            if (work_buf_additional_days < 0) work_buf_additional_days = 0;
             mask.work_buf_additional_days = true;
             continue;
         }

but too negative value could break the work fetch logic.

Adding additional checks in the if (xp.parse_double(tag, "work_buf_***_days", work_buf_***_days)) ... blocks was not enough, because the order of the parameters in preferences file is not fixed or one of them could be left out completely. (BTW, this overlong line seems to reveal some trac wiki formatting bug, at least during preview.)

Possibly both checks in the parse blocks could be left out, keeping just the two checks at the beginning of the while() loop just prior to return 0; lines.

[Nicolas]

Mark as having a patch.

[Richard Haselgrove]

I think this is going to be really unfriendly and confusing for ordinary users - "I'm going to be away for a week, but I can fit in a couple of days work before then. So what figure do I type in this box? Minus five? Huh?" How many other programs do you use that work like that?

Far better to finish the job of decoupling CI and AC - lose the concept of 'additional' entirely. One figure to define connect interval (only): the other figure to define cache size (only). What you see is what you get. And returning to the original 10 days maximum work buffer, rather than the current 20 days, will be better for project server stress, timely scientific results, and prictical guidance by help-desk volunteers.

[Richard Haselgrove]

Practical guidance, that would be. Sorry.

[Pepo]

Replying to Richard Haselgrove:

I think this is going to be really unfriendly and confusing for ordinary users - "I'm going to be away for a week, but I can fit in a couple of days work before then. So what figure do I type in this box? Minus five? Huh?"

I'm going to be away for a week with my notebook, during the time the machine will be switched off for some three days. Thus -3 in addition to 7 days connection interval. I know that from the ordinary user's point of view it is ugly.

From the early Boinc times I (maybe incorrectly) remember having the settings available to specify the cache size and connection interval. I could be wrong. But if the functionality is now available in the client, there is no (at least technical) constraint for all possible graphical interfaces (be it managers or forum web pagesweb) to introduce these settings and calculate the ugly value from 'cache size' and 'connection interval' values. Or for the client to calculate its own values internally.

Far better to finish the job of decoupling CI and AC - lose the concept of 'additional' entirely. One figure to define connect interval (only): the other figure to define cache size (only). What you see is what you get.

Indeed. It was possibly deprecated during the works on the new scheduler versions since some two-three years ago (connect every x interval and work_request_factor multiplier) and in the times users wished the 'return_results_immediately' functionality back. Possibly it happened intentionally? Anyway, now it could be reintroduced again.

And while looking around, I've found out that actually JM7 introduced the idea of negative "extra work" setting a while back, see the ​(boinc_dev) Idea for extra work and vacations. email thread (and ​my response), started on 15 Sep 2007 12:03:06 UTC.

[davea]

The client keeps track of the fraction of time during which computation can be done; that should address this issue