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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
