Sure, but how long would it take? If you do nothing, the problem will ease by itself, but while you're waiting the natives get restless.
[email protected] wrote: > 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. > _______________________________________________ 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.
