How come BitTorrent slows down the rest of my connection?

[Blaperty]

I have a 10 Mbit cable connection (and I've had that independently checked), but when I have any kind of Bittorrent download running, it lags up the rest of my connection. I can be downloading a file at about 800 Kbits/second via HTTP, and surf the web, or stream a video with no noticeable lag, but even a very low bandwidth torrent download, and the whole of the rest of my connection (even other machines on the newtork) takes ages.

How could this be? I understand that BT uses a lot of sockets, but really, should that matter? I mean, shouldn't Firefox just grab 1 socket, and suck down a web page hell for leather, with all available bandwidth? And doesn't the TCP/IP stack have bazillion more available sockets than BT would ever use anyway?

So if it's not the sockets, it's not CPU load (which it's not), and if it's not using more than 10% of my bandwidth, how is Bittorrent slowing everything down?
Amusing that someone would quote Ted Stevens, and then give answer that misunderstands the question.

No Torrents running. Big web page loads in 1 second.
1 Torrent at 20 K/s running. Big web page loads in 10 seconds.
10 Torrents running at 800 k/s collectively. Big web page loads in 11 seconds, and it's not the system resources - I can play CoD 4 with this running in the background.

Why?

 

[mmmme1]

Cause its constantly requesting connections to other clients, meaning its constantly sending data to others to be approved to send you stuff. BTW, isp don't like torrenting much, so they like to chop your internet if you use it.

It shouldn't slow EVERYTHING down, just your internet speed.

 

[Jeff]

The simplified description of the problem is that the cable/dsl modem can only handle one packet at a time. In that sense, it really is like a tube . When you have a TON of large bittorrent packets queued up on either side, the normal traffic packets have to wait and be handled in the order that they came in, so you end up with a really high latency - and it's latency that really kills you - web pages are really very small, compared to torrents, but you're waiting 10 seconds just for the request to go through, not for the actual data transfer to happen.

The way to fix this problem is to let some packets "skip" the queue and get handled immediately. To do this, you need a more intelligent queue that can identify and prioritize packet types, and you'll have to move the queue to that point in the chain. The cablemodem and router you have probably don't have this ability, which is called QoS (Quality of Service).

Here's how I do this:

1). Get a Linksys WRT54G router, or similar. They cost $40 or less on eBay and other sites.
2). The linksys router can be re-flashed with an open source replacement firmware called dd-wrt. dd-wrt provides a lot of additional features, such as QoS
3). QoS (Quality of Service) is the mechanism for prioritizing data packets - giving web browsing a higher priority than torrent, for example.
4). You'll want to set the maximum upload and download bandwidth of the router to be slightly less than the actual maximum of your cable provider. This will force the bottleneck to be the router instead of the modem. Since the queue is now waiting to get through the router instead of the modem, it can let some packets be handled quicker, and save others to only be processed when there is free time.

For example, if you have a connection that is 1.5Mb/s down and 40kb/s up, you would set your maximums to be 1.4MB/s down and 35kb/s up. If you had only one single transfer going, this would technically be slower with QoS than without....but when you have multiple transfers or other connections, it's not about just throughput - it's about balancing the need for high throughput with the need for low latency.

It's like night and day when you first use this. I run an SSH and web server on my home machine, and before QoS, if somebody was accessing the web server, it would saturate the pipe - each keystroke in SSH had a delay before appearing to the point where it was unusable. But with QoS, the relatively low data rate of SSH was given a higher priority than the web server, so it appeared responsive even when the web traffic was high.