Mark Pottorff wrote: > It would seem that having the server be able to accept a connection, > and then direct the client on any preferred backoff would be ideal. [...] > establish a simple 1-5 system expressing how busy it is. The client > then weighs time to deadline against likelihood of future internet > connection to assess whether it has an upload of sufficient priority > or not. And if not, it delays starting next upload. > > Really the objective is that all result files across the user base > get uploaded in priority order. Where priority takes in to account > bandwidth user and project have available, deadline, file size, etc. > > Same is true for downloads. If server is drowning in requests, you > want to be servicing the starving clients first, not those with > full-time networks and fat work caches. And only to the extent that > they aren't starving anymore, until the contention is resolved. [...]
Good points there I agree with. Do not forget that there are still users that are only on intermittent 56.6kb/s DIAL-UP connections... A lack of traffic management is indeed a BIG problem. The software people cannot just shrug it off as a "network problem". In reality, traffic management is a problem affecting the entire system. I rather like the idea of clients requesting a time slot from the project server for when they can upload their data and at what rate... Hence have: client -> server: Request to upload at xxx-kb/s, I'm on yyy link, ccc available cache; server -> client: Granted at zzz time. Where yyy says how long this link is available for and how frequently it is available. (eg: Numbers that indicate dial-up?!) (Aside: User client-sourced information will avoid loading the central db... Or would that be too open to abuse from "modified" clients?) However, in the immediate scheme of things, I think the dynamic tweaking of client upload rate and of the backoff parameters and a slow decay to the backoff times are more easily achievable. Dial-up users take their chances but with a great disadvantage to all others during overload conditions. For a quick fix, perhaps the project servers should just give an immediate NACK to excess connections when the link is more than 80% utilised. Tweak that number for maximum throughput during recovery periods. Regards, Martin -- -------------------- Martin Lomas m_boincdev ml1 co uk.ddSPAM.dd -------------------- _______________________________________________ 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.
