Josef W. Segur wrote:
> On 13 Jul 2009 at 1:06, Martin wrote:
> 
>> I suggest a 'first try' *max simultaneous connections of 150* for
>> uploads *and 20 for downloads* Adjust as necessary to keep the link
>> at an average that is no more than *just 80 Mbit/s*
> 
> 20 for downloads won't work. I'm on dial-up like Mikus (though I don't
> know if he's doing s...@h). Maybe 5% of the 292343 active s...@h hosts, call 
> it
> 15000 or so, are communicating at ~50 kbps. On such a host the download
> connection for a setiathome_enhanced workunit lasts for about a minute.
> If each such host downloads on average one workunit per day your 20
> connections are tied up continually. An Astropulse workunit takes 30
> minutes or so to download...

Good point.

The danger there is that the dial-up users may steal all the 
connections. The fast connections will clear quickly. The dial-up users 
will grab a connection and hold it for a 'long' time as you describe...

This is where the server must dynamically adjust the connections limit.

Hence the point about the server (dynamically) adjusting the connections 
limits to maintain an approximately 80% maximum link utilisation for 
each of uploads and downloads. Also note that the adjust should also be 
made until a proportion of the connections are available but unused for 
the case when the project isn't busy with transfers.

That should self adjust to accommodate any real-world mix of slow and 
fast connected users.


> To get back to BOINC development, I think a fairly simple change would
> help a project tune work delivery to available bandwidth. The Feeder
> ensures there are 100 results available to send every 2 seconds. If that
> 2 second sleep interval were changed to a variable, the amount of work
> which is available to be sent could be adjusted to circumstances. Make it
> adjustable by a script which senses when dropped connections exceed some
> small minimum, perhaps. Or simply have project staff adjust it when
> conditions change. Projects which never run into difficulties (if there
> are any such) would keep the 2 second default.

I'd suggest to have the bursts much smaller, say no more than 1 second 
bursts of WUs. Most routers can only buffer a little more than a second 
of link data without data loss.

That scheme will work well for limiting downloads to a controlled limit. 
You still need to do something about an upload scramble whilst clearing 
the backlog after an outage.


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.

Reply via email to