Re: BitTorrent's effect on bandwidth
Quaoar
> I have a network utilitization problem caused by BitTorrent.
>
> My friend uses BitTorrent, I think the latest one from bittorent.com.
> He tries to keep the upload speed set to 50kbs.
>
> Somehow, this 50kbs speed setting causes a cable internet connection
> of 4Mbs download/256kbs upload to heavily slow down. Where usual
> latency was 60 to 70 milliseconds, his bittorrent increases the
> latency to greater than 1250 milliseconds. QoS functions do not help
> the situation.
>
> I do not mind the use of BitTorrent, but I do care about its effect on
> the network.
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
> News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the
> World! 120,000+ Newsgroups ----= East and West-Coast Server Farms -
> Total Privacy via Encryption =----
In the 'usual' situation, the recommendation is to keep upsteam to less
than 80% of maximum, about 200kbps in your case, to prevent completely
throttling the downstream bandwidth. So 50kbps should do little to your
shared bandwidth unless the other downstream is also saturated, leaving
you nothing down but plenty upstream. I suspect that the other
connection is in fact taking much if not all of the downstream.
A separate issue with the router not handling many connections could
also account for the problem.
Ken
Could also be that you are confusing bits and bytes. 256 kilo-bits is
only 32 kilo-BYTES. i would imagine the setting in the torrent program
would be in kilo-bytes, which is actually 400 kilo-bits. Just a thought.
Hop-Frog
news:43098d1c$0$5403$5a62...@per-qv1-newsreader-01.iinet.net.au:
> only 32 kilo-BYTES. i would imagine the setting in the torrent program
> would be in kilo-bytes, which is actually 400 kilo-bits. Just a
> thought.
Right. All the clients I know use kilobytes. The maximum global upload
speed (for all torrents combined) should be throttled at about 25 kiloBYTEs
per second.
The rule of thumb is that you should cap at ~80% of the upload capacity; to
make the conversion from kilobits to kilobytes, and multiply by 80% at the
same time, just divide by 10. (Divide by 8, then multiply by 8/10.)
--
I am simply Hop-Frog, the jester--and this is my last jest.
(Please note: to reduce spam, I periodically modify this address. If an
email to me bounces, increment the number in my address by one.)
speeder
>I have a network utilitization problem caused by BitTorrent.
>
>My friend uses BitTorrent, I think the latest one from bittorent.com.
>He tries to keep the upload speed set to 50kbs.
>
>Somehow, this 50kbs speed setting causes a cable internet connection
>of 4Mbs download/256kbs upload to heavily slow down. Where usual
>latency was 60 to 70 milliseconds, his bittorrent increases the
>latency to greater than 1250 milliseconds. QoS functions do not help
>the situation.
>
>I do not mind the use of BitTorrent, but I do care about its effect on
>the network.
It definitely looks like you've saturated the upstream but if you got
the numbers right that shouldn't be happening on a single computer.
Limiting at 50kbs for a total upstream of 256kbs gives you plenty of
room.
You say there is a network so what are the other machines doing? Can
you take their Internet traffic out of the picture to troubleshoot?
You mention QoS didn't help. What exactly did you try to do? There is
a QoS driver on Windows network settings, that won't get you anywhere
for example. Are you using a wireless connection for BitTorrent? It
shouldn't be a problem in principle but getting wireless to work
effectively is tricky business so that could be playing a part as
well.
speeder
>The other machines are mostly idle on the internet. I will label the
>3 computers A, B, and C.
>
>C is a roommates computer that is only used for web-browsing and
>email.
>
>B is my computer, connected via wireless due to the lack of enthusiasm
>to put wires through an old house, does web-browsing, newsgroups, and
>MMORPG (World of Warcraft). When BitTorrent is not active, WoW
>latency is 50ms. When BitTorrent is active, WoW latency is greater
>than 1200ms.
>
>A is the friend with BitTorrent's machine.
>
>Only C and A are wired. B is not because it is on the second floor,
>but it connects to the router through wireless and is very reliable.
>
>The router is a Linksys WRT54GS v1.0 firmware 4.70.6. The cable
>internet is provided by InsightBB with 4Mbs down/384kbs up. 384kbs is
>the right speed.
>
>Like I said, with BitTorrent running, all the computers access the
>internet fast, but with BitTorrent running, a few bandwidth tests
>think it is doing 350kbs download, but the upload rate is hardly
>touched.
>
>I am using the QoS on the router. I have tried setting the BitTorrent
>ports to low priority and a few others to higher priority.
I don't see anything wrong with your setup, and the performance you're
getting is consistent with the heavy usage your making of it. BT is
going to quickly use all the upstream it can and that will make all
others on the network take a toll. There is no getting around that,
the only thing you can attempt is define how much is that toll. The
simplest solution is to throttle it back by 80%, WOW is very demanding
on latency so more might be needed. The problem with that is that BT
is cut back on what it can do even if the others aren't using
anything. That's where good QoS come into play.
QoS was designed to solve this kind of problem, but QoS implementation
is not equal in all devices/systems. Each router/firmware
implementation will have its own performance. And the way you set it
up (with the available features that vary) will also have a huge
impact. I also think it's not realistic to expect 50ms latency with BT
and QoS, at least not in a home router.
I've read comments on how people couldn't get the stock firmware QoS
to work with VoIP, for example. If you think you've exhausted the QoS
possibilities of your current firmware try something different there
are plenty more capable options.
Based on your posts I would think you didn't throttle BT properly.
Confusing bytes/bits is an all too common mistake as well. Make sure
you eliminate this possibility before venturing further.
speeder
>What KBps upload speed would you recommend for 384Kbps? Also, what
>would it be for 512Kbps?
384 Kbps /8 = 48 KBps => 80% = 38 KBps maximum
512 Kbps / 10 = 51 KBps maximum
Start with those and see what happens with your network performance.
If it is not satisfactory, work your way down with the limit until you
reach an acceptable level.
DaveG
Additionally, it's worth bearing in mind that for every data packet
received there is a corresponding ack packet sent. If the BT
user has throttled torrent upstream but is using large amounts of
downstream then yet more of the upstream will be consumed by those ack
packets.
This is a becoming more serious with some ISPs wildly asymetric offerings.
My ISP is about to upgrade 2 and 4Mb users to 10Mb (for free, I might add
and pricing it at the current 2Mb rate <g>). Upstream will only be 384Kb.
A *lot* of that upstream will be taken by ack packets if the full 10Mb
downstream is being utilised.
--
Dave
Beauty is in the eye of the beerholder
Chip Orange
"Quaoar" <qua...@tenthplanet.net> wrote in message
news:UbidnbEA_fA...@comcast.com...
I too think a less than stellar router may be the real issue; especially if
what you have is one of those under $50 specials from some local electronics
store.
kim
>I have a network utilitization problem caused by BitTorrent.
>
> My friend uses BitTorrent, I think the latest one from bittorent.com.
> He tries to keep the upload speed set to 50kbs.
>
> Somehow, this 50kbs speed setting causes a cable internet connection
> of 4Mbs download/256kbs upload to heavily slow down. Where usual
> latency was 60 to 70 milliseconds, his bittorrent increases the
> latency to greater than 1250 milliseconds. QoS functions do not help
> the situation.
>
> I do not mind the use of BitTorrent, but I do care about its effect on
> the network.
The most asked and replied-to subject in this newsgroup. Your friend should
limit his upload to no more than 80% of its theoretical maximum to avoid
flooding the connection with acknowledge signals. With a 256kib/s connection
that should be about 20Kib/s. Even so he will never get downloads of more
than about 120Kib/s due to practical considerations.
(kim)
Locutus
get a dedicated modem and PC for BT
you wont have to worry at all
you can give it full speed
Mark Schreiber
24/7, uncapped, without hurting the performance of your webbrowsing or
the network performance of anyone else's computer on your LAN.]
On Mon, 22 Aug 2005 01:54:37 -0500, wrote:
> He tries to keep the upload speed set to 50kbs.
You probably mean 50kBps, not 50kbps -- bytes, not bits. ISPs rate their
connections in bits per second, and most applications in bytes per second
(one eighth as much).
> Somehow, this 50kbs speed setting causes a cable internet connection
> of 4Mbs download/256kbs upload to heavily slow down.
This is because 50kBps seen by the application is roughly equal to
400kbps seen by the cable modem (the cable modem actually sees a bit more,
due to retransmitted packets and header overhead). Your friend is trying
to send data faster than his cable modem can handle it. Normally, on the
Internet, this is no problem -- a router receiving more data than it can
send will simply drop some packets, the application will notice this (this
is how TCP is intended to determine the proper rate at which to send
data). Unfortunately, this is *not* what cable modems do (see below).
> Where usual latency was 60 to 70 milliseconds, his
> bittorrent increases the latency to greater than 1250
> milliseconds.
This is caused by the fact that cable modems have a ridiculously large
outbound buffer.
If this buffer ever fills up (which happens whenever the cable modem's
outbound is saturated -- common with the use of P2P), your latency will
absolutely skyrocket.
If your cable modem's buffer can store a second worth of transferred data,
then your latency will reach one second.
What you can do is to keep your BitTorrent client capped at, say,
25kBps -- that's 200kbps, which is close to but probably far enough
below the modem's max that you won't start filling up the buffer. The
problem is that any other apps you run that use more than that
remaining 50kbps (6.25kBps) will start filling the outbound buffer and
increase the latency until the buffer can empty again. There is no
way that I am aware of to reduce the size of the buffer on commercial
cable modems.
The only box that knows how much data is going out of the network and
how full the buffer is is the cable modem. You can't modify the cable
modem, because sadly enough, they aren't open platforms. However, you
*can*, if you have sufficient Linux expertise, do the next best thing,
and stick a router right between the cable modem and the rest of your
network. It is possible to build a router (out of, say, a Linux box)
to correct this deficiency in your cable modem. It is possible that
some inexpensive "consumer broadband router" of the sort that Linksys
and D-Link sell can also do this; I am not familiar with the current
feature range of these routers. I have done this with a full-blown
Linux box with excellent results.
Basically, what you need to do is to ensure that the router never
sends a higher rate of data than the cable modem can send -- if it
receives more data than it can send, to make it just drop the
remaining packets. This means that the cable modem's buffer never
fills up and your latency doesn't rise up to the one second or
whatever the cable modem stores in its buffers.
There are a number of rate-throttling scripts available for Linux
(lartc.org is a good place to start digging around).
That solves one problem. Now, all the machines on your network need
not no longer worry about a second or more (I've seen DSL modem
outbound buffer latency up above ten seconds on one network) of
latency. Blame the broadband modem designers.
Next problem comes in with the fact that bandwidth on your network is
not properly shared.
See, theoretically one person on a simple IP network can totally flood
a router by blasting out packets as fast as possible (once type of
this is called "ping flooding"). For most traffic on most networks,
however, we use TCP. TCP does a sort of rudimentary load balancing on
routers it passes through. The idea is that a router will start
dropping packets if it is overloaded. A TCP stack sending data
through a TCP connection can detect dropped packets, and take them as
an indication that it should slow the rate at which it sends data --
it will then start increasing the rate at which it sends data on that
connection until it picks up another lost packet, at which point it
will cut the rate again).
This works pretty well if Bob has one connection from his computer
(maybe a telnet connection or an http connection), and Joe has one
connection from his computer. Both Bob and Joe ramp up the rate at
which they try to send packets until about the same amount. Maybe Bob
tries to use a few more connections, but in general, hosts use about
the same number of connections.
P2P clients, however, often use *hundreds* of TCP connections
(BitTorrent not as much so as some other protocols, like eDonkey).
What happens, more or less, on a simple network with no fancy traffic
shaping going on, is that Bob (with eDonkey and 99 TCP connections
open) gets 99% of the bandwidth, and Joe (with telnet going through a
single connection) gets 1% of the bandwidth.
The thing that most people would like to see done would be for the
router (which can, at least in theory, know that Bob is trying to send
data a lot more frantically than Joe) split available bandwidth in
half between Bob and Joe.
You can do this too, with a Linux router. You need to set up an HTB
tree with tc with a child node for each machine out there.
Then, there's one more remaining nasty problem with consumer broadband
connections. See, there are some applications where you aren't very
concerned about packets being dropped if there isn't enough bandwidth
available for a moment. FTP or BitTorrent are great examples. Nobody
cares if their FTP or BitTorrent connection slows down momentarily,
but it's incredibly annoying if their web browsing gets sluggish (or,
even worse, their ssh connection).
What you'd like to do is, if you're web browsing and uploading a file
to someone, is use any bandwidth available to do your web browsing
*first*, and then hand the leftover bandwidth for the program trying
to upload the file to use.
The folks that designed IP thought of this, and stuck a few flags
called Type of Service (ToS, not to be confused with QoS, even though
ToS flags are incredibly useful in doing QoS) flags in the header of
each IP packet, where most of them remain to this day. The problem is
that they envisioned a friendly, helpful Internet, where every person
would indicate that they were sending only low-priority data, and
where a particular person might desperately need high-priority (low
latency) data (such as with an interactive game).
Obviously, this doesn't work in real life, on today's Internet. Every
single person would just set their packets to "High Priority", and be
done with it.
Sure, the backbone routers could solve this problem by remembering
every single host sending data through them and first breaking down
bandwidth evenly to each host, and only *then* sending each host's
high priority data first. The thing is that there are far too many
hosts sending data through most IP routers for those routers to keep
track of what hosts are sending how much data.
So these flags went ignored by all the routers out there, even though
a number of applications (ssh, telnet, ftp, etc) set them. Modern
applications began to not even bother setting them, because the
routers simply ignored them.
However, as it turns out, consumer outbound broadband connections
bring back the need for ToS bits again. They are almost always the
chokepoint when trying to send data. And, the magic thing here is
that the router at that chokepoint (where the cable modem/DSL modem
is) has only a very few hosts to remember data usage for -- just the
hosts on your home LAN. So you can actually take advantage of this.
If your applications properly set the ToS bits, then you can set up
your router to send *any* medium-priority data from your machine
before any low-priority data from your machine. So you can run
BitTorrent maxed and the latency of your web browsing on the same host
will be totally unaffected.
I wish to high heavens that the router engineers at Linksys would get
off their collective rear ends and *implement* some of these things
for consumers in their routers, as they can *wildly* improve
performance for normal usage, but as far as I can know, they aren't
doing so. That means that the only real route to get sane network
performance is to build yourself a router -- you can't buy any
prepackaged consumer broadband router (that I'm aware of) that do
this, despite the fact that lots of them run Linux and could
theoretically do this in short order. (Heck, a competent Linux
network admin could image boxes to do these by the dozens easily --
he'd need a box that's probably a Pentium or higher with maybe 16 megs
of RAM or higher. Probably these requirements are overkill, but
better safe than sorry.)
I've set up a Linux router at my house between the cable modem and the
LAN which implements the following:
*) Rate limits to just before the cable modem/DSL modem's maximum
bandwidth. Latency never rises when the line is saturated.
*) Available bandwidth is fairly and evenly shared between all hosts
on the network. Computer A on the LAN can be running a P2P client
which is sucking down all the outbound bandwidth it can, and Computer
B on the LAN will still have at least half of the bandwidth available
for their own use.
*) ToS bits are used as hard priority bands -- high priority data
(ssh) from any one computer *always* goes out before medium priority
data (web browsing, just about everything else), which *always* goes
out before any low priority data (eDonkey, BitTorrent). This means
that running P2P full blast doesn't affect the latency of your
webbrowsing. I know that at least the following applications properly
set the ToS bits to something other than "medium" priority -- ssh,
telnet, the old-looking command-line ftp, BitTorrent (the official
client), mlDonkey, gtk-gnutella. I suspect that other applications do
so as well, but these are all the ones I'm familiar with.
I'll post the perl script that I use at the bottom of this post.
Sorry, I know this is nowhere near a "click, run, forget it" solution
for the Windows crowd -- but that's gonna be the case until someone
makes a pre-done Linux router distro that can do all this or Linksys
decides that consumers actually want routing capable of keeping P2P
usable. It's suitable for anyone that has a Linux router up and
running and doing NAT for their LAN and just wants reasonable traffic
shaping as well. The main interesting and unusual thing that this
script (I have it executed every 15 minutes on the router) does is to
skim a list of MAC addresses out of the ARP cache on the router
(basically, the closest convenient thing to a list of hosts "on the
network" that doesn't require manual configuration) and then evenly
share bandwidth between those MAC addresses. The only three things
that have to be set are $external_interface (which has to refer to the
NIC on the Internet/cable modem side of the router),
$internal_interface (which has to refer to the NIC on the LAN side of
the router), and $ceil (which, in *bits* per second is the rate at
which you want the outbound from your network capped at the router --
it should be *below* the maximum rate the cable modem can send,
because it doesn't always send at ideal, 100% speeds...and if you see
that latency creeping up when the outbound on your modem is saturated,
you have it too high).
> QoS functions do not help the situation.
QoS is a generic term -- "QoS" can involve doing almost anything to a
network involving traffic shaping. There's no such thing as a bullet
point for "Can do QoS" (though folks like Linksys do tend to convey
this impression).
>
> I do not mind the use of BitTorrent, but I do care about its effect on
> the network.
I can tell you that it is absolutely possible to use P2P applications
24/7, full-blast, no caps on the application directly, and continue to
use your network as if there is absolutely no impact (other than the
fact that throughput will have to be split evenly between hosts trying
to saturate the network).
Anyway, here's the script I use.
#!/usr/bin/perl
$external_interface="eth1";
$internal_interface="eth0";
$ceil=240;
@arp_dump=`arp -an`;
chomp @arp_dump;
@internals=grep(/$internal_interface$/, @arp_dump);
foreach $line (@internals) {
if ($line=~m/\((.*)\)/) {
push @ips, $1;
}
}
system("tc qdisc del dev $external_interface root 2>/dev/null");
system("tc qdisc del dev $internal_interface root 2>/dev/null");
system("iptables -t mangle -F");
$per=$ceil / ($#ips + 2);
system ("tc qdisc add dev $external_interface root handle 1: htb default 2");
system("tc class add dev $external_interface parent 1: classid 1:1 htb rate "
.$ceil."kbit ceil ".$ceil."kbit");
$id = 10;
system("tc class add dev $external_interface parent 1:1 classid 1:2 htb rate "
.$per."kbit ceil ".$ceil."kbit");
foreach $ip (@ips) {
print "adding ip $ip\n";
system("tc class add dev $external_interface parent 1:1 classid 1:".$id.
" htb rate ".$per."kbit ceil ".$ceil."kbit");
system("tc filter add dev $external_interface protocol ip parent "
."1:0 prio 1 handle $id fw classid 1:$id");
system("tc qdisc add dev $external_interface parent 1:$id handle $id: prio");
system("iptables -t mangle -A PREROUTING -p ip --src $ip -j MARK"
." --set-mark $id");
$id++;
}