David Brown wrote:
On Sun, Mar 09, 2008 at 09:34:34AM -0700, Andrew Lentvorski wrote:
[EMAIL PROTECTED] wrote:
Maybe you could use the --max_upload_rate flag when you start
bittorrent?
From man bittorrent:
--max_upload_rate kbytes
maximum rate to upload at in kilobytes, 0 means
no limit
(default 0)
You can, but that doesn't really do what you want either. You'd
ideally like to blast out a couple of seeds and then throttle way back.
I certainly don't want to do that. If I saturate my relatively slow
uplink, my downlink suffers because responses get queued instead of being
sent. If my uplink is only partially saturated, then the downlink will
continue to work at full speed.
Well, I wasn't really talking about an individual attempting to seed on
a slow upload link. I was talking about it in the context of having a
big pipe like Amazon where you wanted a minimum latency upload but then
that you didn't want to get bent over a barrel about bandwidth charges.
I _never_ want it to saturate my uplink, or my entire net connection
becomes nearly worthless. VOIP stops working and downloads are unpleasant.
I can let it dribble away at a fraction of my total uplink and hardly
notice that it is running. I suspect most home internet connections will
be like this.
Actually, what you *really* want is for torrents to consume all your
bandwidth but immediately relinquish some the moment you need it for
anything else.
My main concern is that the max_upload_rate is global, not per torrent.
What you are highlighting is the fact that TCP flow control isn't really
working in the presence of multiple flows. Quite a few papers are
starting to appear about this.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
