4 ms·

Wait a minute. Is it the CPU and memory factor on the router that causes the "internet is slow, somebody close your torrents" nuisance? I always thought it was

Wait a minute. Is it the CPU and memory factor on the router that causes the "internet is slow, somebody close your torrents" nuisance? I always thought it was the bandwidth getting choked. Could someone expand on this topic?

oz 14y ago
Every TCP/UDP endpoint (such as a client or a server) maintains a state-table. As you might guess, it stores the state of each connection. You can view it using the 'netstat' command on Windows and Linux. Bittorrent tends to create several entries in the state-table (since you're typically connected to hundred of seeds/leeches), which are each stored in memory, and uses up CPU resources to setup/maintain/teardown. So if you were downloading a file via, say, Rapidshare, there'd be probably 1 TCP (you can configure your browser to use more) connection for your router to track, and do the necessary TCP handshakes, acknowledgments, RWIN scaling etc. Multiply all that's necessary for 1 TCP connection by N, where N is the number of peers you're connected to, and the limited resources on a $60 router get used up fast. Early models of the now-famous Linksys WRT54G could reliably be crashed by torrenting while using stock firmware. A power-cycle was necessary to get it running again. Fun times. However, all this only applies if you're running the router in NAT mode, which means the router takes the IP address from your ISP, and acts as the endpoint on behalf of your computer. If the router is running in bridged mode, then your computer acts as the endpoint, as much more equipped to handle large numbers of TCP connections. Edit: Formatting, Grammar.
- pyre 14y ago
  > Early models of the now-famous Linksys WRT54G could > reliably be crashed by torrenting while using stock > firmware. A power-cycle was necessary to get it > running again. Fun times. I had an older Linksys model, but it would get into a state where the max bandwidth it would allow would be 32kB/s.
seany 14y ago
This is actually a two part problem. oz captured half of it (maintaining hundred of connections in the NAT state table). It can also be caused by saturating your upstream bandwidth, which causes your devices send buffer to fill. When that buffer is full you end up with your packets waiting in the buffer (which is normally fifo). What makes this very noticeable most of the time is the ack part of the tcp connection getting stuck, there by forcing the remote server to wait to send you the next packet. There are ways to mitigate that kind of thing. the simplest being keeping upstream bandwidth levels limited to slightly less than your upstream connection speed. Traffic prioritization schemes also exist letting you have some say in the buffer order ( always putting acks, icmp, and ssh first in line for instance ).
- pyre 14y ago
  You can also mitigate the NAT state table issue by limiting the amount of peers your torrent client connects too. Some clients allow you to set a global max, and others only allow a per-torrent max (e.g. rtorrent).

oz 14y ago

Every TCP/UDP endpoint (such as a client or a server) maintains a state-table. As you might guess, it stores the state of each connection. You can view it using the 'netstat' command on Windows and Linux. Bittorrent tends to create several entries in the state-table (since you're typically connected to hundred of seeds/leeches), which are each stored in memory, and uses up CPU resources to setup/maintain/teardown. So if you were downloading a file via, say, Rapidshare, there'd be probably 1 TCP (you can configure your browser to use more) connection for your router to track, and do the necessary TCP handshakes, acknowledgments, RWIN scaling etc. Multiply all that's necessary for 1 TCP connection by N, where N is the number of peers you're connected to, and the limited resources on a $60 router get used up fast. Early models of the now-famous Linksys WRT54G could reliably be crashed by torrenting while using stock firmware. A power-cycle was necessary to get it running again. Fun times. However, all this only applies if you're running the router in NAT mode, which means the router takes the IP address from your ISP, and acts as the endpoint on behalf of your computer. If the router is running in bridged mode, then your computer acts as the endpoint, as much more equipped to handle large numbers of TCP connections. Edit: Formatting, Grammar.

pyre 14y ago
> Early models of the now-famous Linksys WRT54G could > reliably be crashed by torrenting while using stock > firmware. A power-cycle was necessary to get it > running again. Fun times. I had an older Linksys model, but it would get into a state where the max bandwidth it would allow would be 32kB/s.

seany 14y ago

This is actually a two part problem. oz captured half of it (maintaining hundred of connections in the NAT state table). It can also be caused by saturating your upstream bandwidth, which causes your devices send buffer to fill. When that buffer is full you end up with your packets waiting in the buffer (which is normally fifo). What makes this very noticeable most of the time is the ack part of the tcp connection getting stuck, there by forcing the remote server to wait to send you the next packet. There are ways to mitigate that kind of thing. the simplest being keeping upstream bandwidth levels limited to slightly less than your upstream connection speed. Traffic prioritization schemes also exist letting you have some say in the buffer order ( always putting acks, icmp, and ssh first in line for instance ).

pyre 14y ago
You can also mitigate the NAT state table issue by limiting the amount of peers your torrent client connects too. Some clients allow you to set a global max, and others only allow a per-torrent max (e.g. rtorrent).