It doesn't help immediately, but it will help reduce the length of the problem.
jm7 [email protected] wrote on 07/14/2009 12:24:19 PM: > "Lynn W. Taylor" <[email protected]> > Sent by: [email protected] > > 07/14/2009 12:24 PM > > To > > [email protected], BOINC dev <[email protected]> > > cc > > Subject > > Re: [boinc_dev] Optimizing uploads..... > > Slowing work assignment is going to help, but if we're talking about too > many simultaneous downloads, it's already too late: the downloads are > already assigned. > > If we're talking about too many uploads, those were assigned possibly > days ago -- slowing work assignment today will take a while to show a > result. > > At the same time, just battering away at the servers will also show some > success, and as uploads or downloads complete, by itself that'll lower > the load. > > To be effective, you want something that can produce a result fast. We > may not be able to get that, but should be able to get a result in an hour. > > -- Lynn > > [email protected] wrote: > > Unfortunately, the upload server cannot know anything about the host that > > is sending the file up as that would require database access per upload. > > The upload server could possibly inform the rest of the server system about > > failed uploads due to overloads. This could be used to limit task creation > > and delay deadline enforcement. > > > > jm7 > > > > > > > > "Josef W. Segur" > > <jse...@westelcom > > .com> To > > Sent by: [email protected] > > boinc_dev-bounces cc > > @ssl.berkeley.edu "Lynn W. Taylor" <[email protected]> > > Subject > > Re: [boinc_dev] Optimizing > > 07/14/2009 10:28 uploads..... > > AM > > > > > > > > > > > > > > > > > > > > You're correct that skipped opportunities to try uploads do not count as > > "failed", they simply don't count at all. Typical hosts with continuous > > connection try again every two hours on average because the actual backoffs > > are randomized, so get 12 retries a day until the upload problem is > > cleared. Hosts with only one hour a day connectivity will retry at the > > beginning of that one hour and have a 25% chance of another retry in that > > one hour. > > > > With failed uploads disabling downloads, it seems to me that hosts with > > limited connect times due to IT department restrictions ought to be > > given the best possible chance of getting new tasks when they are allowed > > to connect. > > -- > > Joe > > > > > > On 13 Jul 2009 at 21:38, Lynn wrote: > > > >> I'm actually limiting connectivity to 1 hour out of 24. > >> > >> With the current backoff algorithm, the timer runs out at four hours, > >> the state goes to "suspended" and the moment the appointed hour rolls > >> around the uploads start, two by two. > >> > >> If those first two succeed, then the rest would continue, with two > >> connections at all times -- no matter how many you had. > >> > >> I don't think attempts while suspended would count as "failed." > >> > >> -- Lynn > >> > >> Josef W. Segur wrote: > >> > >>> 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. > > > > > > _______________________________________________ > > 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. > _______________________________________________ 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.
