On 12 Jul 2009 at 20:42, Nicolás wrote:
> El Dom 12 Jul 2009 19:32:14 Mikus Grinbergs escribió:
> > I understand that for a project with more than 100000 active
> > clients, situations will arise where the servers are the bottleneck,
> > and need to be "protected" from overload. But I have a
> > philosophical problem with restraining the _clients_ when it is the
> > _servers_ that get overloaded. To my mind, if a project cannot
> > afford the hardware to service 100000 clients, then it should not
> > *accept* 100000 clients.
> >
> >
> > I myself do not run the way an "average" BOINC participant does -- I
> > run off-line. Once a day I connect my client machines to the
> > internet, "squirt" work up and down - and disconnect. If a 'ready'
> > result gets "backed off" instead of being uploaded during this
> > "squirt" -- it has to wait until tomorrow's connection for the
> > upload to be tried again. If that makes the result miss its
> > deadline - TOO BAD - I consider it the fault of the project for not
> > accepting the upload, not my fault for not having the kind of
> > connection that would wait around for the server to get 'ready'.
> >
> > And there are many projects which "throttle" the assignment of work
> > (by enforcing a "minimum interval" between work requests from the
> > same client). Little do these projects realize that my multiple
> > client_machines are ready and willing to perform lots more crunching
> > for them -- but they never see any follow-on requests from me, since
> > I have already disconnected before their "minimum interval" expires.
> >
> >
> > I realize that you have to design for the "average" participant.
> > But as long as BOINC supports specifying an 'interval between
> > connects' of more than 24 hours, I for one will definitely make use
> > of the way-of-doing-work that offers. Please keep in mind the
> > implications -- for any proposal that relies on "backing off" before
> > retrying -- of the possibility of a connection that, rather than
> > going idle, will simply close down (for the next 24 hours, or more).
>
> Maybe there should be a setting called simply: "I have a permanent Internet
> connection".
>
> If the user has a permanent connection, throttle if needed to lower server
> load, as is being discussed between Martin and Lynn. If the user is on
> dialup, upload as much as you can while you can!
>
> Or maybe the client should try to automatically figure out whether the user
> has intermittent Internet; otherwise users with a permanent connection could
> set the setting to say they don't have one just to force immediate uploads,
> causing unnecessary server load.
This would be particularly needed for accounts which include a large number
of hosts behind a corporate firewall or similar, and are only allowed
communication for a short period once a day or once a week.
My suggestion is to reduce the retry count for each retry attempt skipped
because a host has network activity turned off. A rough approximation of
that could be done by saving the time a host disables network activity,
get the interval when it is reenabled, divide that by half the maximum
backoff and subtract the integer portion of the result from the retry
count (with a floor of 0 retries, of course). A host with network activity
disabled for 23 hours out of each 24 would automatically be back at minimal
retry count and therefore at minimal backoff at the beginning of each
active period, but a short period of manually disabling network activity
would have no effect.
--
Joe
_______________________________________________
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.
