Laptop running slow

Ahoy,

achieving great and constant torrent speed based on constant TCP speed first.
There are suggestions in the article about half-open TCP but there are more. And sorry, it needs deeper understanding of TCP, there is no other pill what ease the pain.

Basically a torrent download is group of TCP connections to different machines. This means different “distance” to every connected machine (just for understanding). This “distance” in TCP is measured not in miles but in milliseconds. It is called Round-Trip Time (RTT) or Bandwidth Latency. You can measure your RTT without any expensive equipment, the tool is called ping. Since your connected peers can be anywhere in the world, you should choose some geographically distant servers from abroad to measure your RTT. (And you will be surprised if you just ping your default gateway trough a miss-configured wireless LAN, how large RTT can be even to the way it reaches your ADSL connection.)
RTT is important, the higher the bandwidth of the data flow the same RTT requires more buffer capacity in the low-level TCP operation. Or in another situation there are two servers (torrent seeds) with the same connection speed but their RTT is different, the higher RTT needs larger buffer. This buffer called TCP Receive Window (RWIN). MS opsys is optimised to local LAN, where the RTT is below the 10ms region and small TCP Receive Window is enough even at high speeds. Linux start with 64kB RWIN by default. There can be optimal RWIN between two servers connected over WAN, but there is no optimum for the endless possibilities (speed/RTT) of torrent client machines (no clothes fits for all, no RWIN patch fit for every machine). So with worst case planning we calculate with a connected peer (or webserver) with 500ms delay and its whole troughput as our maximum download. We have for example a 2Mb ADSL line.
2Mbps = 2048kbps=256kBps
This means in every second 256kB of data can be transferred. The 500ms delay is 0,5s so the buffer required is 128kB. So we have to set RWIN size to 128kB.
(128kB is a somewhat good value, for home use the usable values are in the 64-256kB range.)

If we run 4 paralel download with 150 TCP connection each, the overall buffer size is 600x128kB=75MB. If you have a dedicated torrent-machine, it is no problem. But in smaller/older machines this is a massive amount of memory so we have to limit the client side paralel connections or reduce RWIN size 64kB. In uTorrent you can set the overall TCP connections number, in bitcomet you can adjust the number of paralel torrent tasks and the TCP connections for each task. Limiting the overall TCP connections is good anyway, the DSL routers usually cannot handle too much – search the internet about your router TCP handling capacity. Generally the overall TCP connections number should be in the 150-350 region for a general DSL router. So we arrieved back to the question of how-to-configure our bitcomet client to not kill our connection.

Well, the last thing you have to understand is MTU (Maximum Transfer Unit or packet size). The TCP implementation runs on your machine cuts the dataflow into packets. Its size is 1500 by default on windows machines what is the default Ethernet packet size – again fine for your office but not surely the world outside. There are a whole set of different non-ethernet technologies (just think ADSL or cable) outside and even some Cisco technologies like their virtual LAN uses up some space (it adds two bytes to your packet so it will be 1502 large until it comes out from the VLAN). There are exotic MTU lines like satellite connections but we do not count with them now. What happens when the transfer technology has a smaller MTU than your actual packet size? The data is truncated (it is called fragmentation) and a built-in function of TCP is activated, it rebuilds the fragments – but on the costs performance.
It is possible to lower your MTU at your endpoint. Packet headers will be often a bit, but it is better than the fregmentation. Just set the same lower value to ALL of your machines and DSL router, I use 1452 just for sure. In Linux there is an automatic MTU discovery in the kernel for ages so it is not a big deal there.

After all this calculations you can set this parameters (MTU, RWIN) using a free tool called DRTCP.

And a final word, use a linux distro torrent for testing torrent speed, there are usually hosted as whole seeds on large number of machines and even on some servers with excellent connections. uTorrent FAQ gives an example.

Regards,

Incoming search terms for the article:

• speed up your pc radio ad
• speed up ie 6 with win98
• explorer 7 speed it up
• bsnl provides less speed
• connection speed causes

One Response to “Speed up your torrents II”