Hello Max
CPDN has not been using a 1hr server backoff 'almost since the beginning'. CPDN migrated to BOINC some eight years ago, but this backoff is a fairly recent change made a year or two ago. The change was made when climate models, hitherto almost continuously available, became available only in irregular batches depending on the requirements of the research groups. The 1hr backoff prevents a minority of computers from repeatedly requesting new work; it also helps to some extent to spread the available work more fairly among computers. This strategy has been successful in maintaining a cheerful attitude among CPDN crunchers. Tweaking the number of workunits permitted per day per core would not be for CPDN as 'dead simple' as you suggest. There is something wrong with the rather antiquated server version of BOINC being used by CPDN. To my knowledge, the only change that this version allows the programmers to make to the daily task allowance is to -1. For a while it did not even allow this change and started to disobey the then programmer, reverting spontaneously. In addition, a computer's daily task allowance is displayed on its computer page as an apparently random number. The CPDN server, however, appears to apply a different number of tasks per day. If you cannot understand my explanation, do not worry as you are not alone. You may wonder why the CPDN programmers and members have tolerated this eminently defective server version of BOINC for so long. You need wonder no longer as the long-awaited update is planned. We expect the new version to be tested first on the Beta project in case the change is too traumatic for those of us still dragging ourselves into this millennium. Mo PS On other projects am I really allowed to edit my own maximum daily task quota per CPU? On Wed, Jan 15, 2014 at 12:26 AM, Max Power <[email protected]> wrote: > > CPDN has been using a BOINC 3600s RPC backoff almost since the beginning > ... and yes it is 'a little daft'. > > Some 5 or 7 years ago the 3600s backoff was a good idea, but in this era > it is borderline bad programming. For this kind of project -- with its > large datasets that get uploaded and downloaded -- 3123s (or 2345s / 5432s, > random variation a +) would be a better RPC time constant. > > The server and client for this datafield (and RPC timer) don't support a > 'fuzzy timer differential percentage' to allow the RPC time constant to > vary by say 12.5% (variation ranges 0.00 to 50.00 {%}). > > There is another dead simple Client-Server datafiled to fix this, called > something like "Number of Work Units per Client per Day" (UTC day that is) > -- tweaking it to 2 does the same thing. > > In spite of the website modernization, CPDN does not allow one to change > in the "Project Preferences" your local client setting for 1 work unit per > client per day. > > The BOINC Client-Server system should be featured on the "History Channel" > series "Modern Miracles" ... albeit the modern miracle is programming all > the parts to function (much less work right). > > > MP > Deep Space Network @ Home > > > -----Original Message----- Subject: Re: [boinc_dev] RFC: Don't let a task > be in the state "Ready toreport" if its files were uploaded immediately > before > > Given that Moore's Law applies to server hardware too, do we have any > evidence that any current BOINC project server would be over-stressed by > one RPC per hour per active host? CPDN have adopted a 3600 second backoff > between RPCs, but I believe this is mostly to prevent individual hosts > downloading too many new tasks when available. > > I've been running v7.2.36 with the one-hour reporting for three days now, > and I'm pleased with it: with a fast GPU at SETI, I'm reporting up to 20 > tasks at a time, although slower CPU projects can report singly. With > piggyback work fetch applied to the reporting RPCs when needed, I'm seeing > a more even application of Resource Share between projects, with less of > BOINC v7's tendency to lurch between 100% saturation for Project A and 100% > for Project B (as anticipated in ClientSchedOctTen). > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
