One possible solution to this is to have the upload server and scheduler
set a flag in the DB to not enforce any deadlines for 24 hours every time a
NAK is generated because of link overload. (Or make it 25 hours and only
update the flag if it has been at least 45 minutes since the NAK that set
the flag in the first place). The reason for this is that some of the work
that is attempting to be uploaded now is due in that time period, and the
24 hour maximum backoff will make some of it late. The project does NOT
need to generate extra work for itself because it is already overloaded
with work. :)
jm7
Mikus Grinbergs
<[email protected]>
Sent by: To
boinc_dev-bounces [email protected]
@ssl.berkeley.edu cc
Subject
07/12/2009 06:32 Re: [boinc_dev] Optimizing
PM uploads.....
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).
mikus
_______________________________________________
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.
