TorrentFreak

80 Responses

Pages: « 1 2 [3] 4 » Show All

51 Oct 06, 2006 at 14:29 by Markusface

Well i tried this in Bitcomet, no such luck.

Uninstalled it, got uTorrent and set up the whole port forwarding shizz, and wahey!!! Up to 80kB/s d/l :D had to cap my u/l to 25kB/s so I’m just gonna have to leave uTorrent running that little bit longer.

52 Nov 16, 2006 at 05:32 by dammit

can anyone tell me what my upload, download, tcp all those settings should be if my connection is 100mbps.i noticd that my max upload is 55kb/s but i dun know about my max download. can someone tell me whats the best setting? thx in advance

53 Dec 23, 2006 at 21:09 by tcpboy

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 600×128kB=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,

54 Dec 24, 2006 at 17:00 by tcpboy

Ahoy,

there are free servers for checking the correct TCP configuration. The sw runs on them called Web100 NDT (network diagnostic tool). It is a modified linux kernel, what can send the inner TCP parameters to a java interface for further analisation. You can see the results in a java applet window.

To get correct measured paameters, stop all other internet activities.

Some servers:
Argonne web100, USA
http://miranda.ctd.anl.gov:7123/

CERN, Switzerland (yes, the lab where the web was invented)
http://ndt.switch.ch/

NIIFI labs, Hungary
http://rs3.lvs.infotars.hu:7123/

Push the Start button and the communication starts. 20s later the results can be seen pushing the More details button. I copied the intresting part of my results:

“estimate = 39.5 based on packet size = 9Kbits, RTT = 243.37msec, and loss = 1.0E-6
The theoretical network limit is 39.5 Mbps
The NDT server has a 8192.0 KByte buffer which limits the throughput to 262.97 Mbps
Your PC/Workstation has a 255.0 KByte buffer which limits the throughput to 8.21 Mbps
The network based flow control limits the throughput to 0.94 Mbps”

So, RTT is 243ms what is good for a transatlantic link. This server has an enormous 8,2M buffer (!) but on a 10Gbps link it can run only 0,27Gbps (270Mbps) with this RTT.
My 255kB buffer is good on this link upto 8,2Mbps.
There is a network flow limiter somewhere between us, so it limits the speed to 0,94Mbps.

If you make regular measurements and see that your buffer size limits the throughput lower than what you pay for your ISP, try increase the RWIN. But be realistic, as I wrote, for home users the usable RWIN buffer size is in the 64kB-256kB region.

Regards,

55 Dec 24, 2006 at 23:08 by Ernesto

thanks for the comments TCPboy!

56 Jan 15, 2007 at 16:55 by Jord

Was sceptical at first but using your formulas as a guide-line i tweaked with my connection speeds and saw an instant improvement. Thanks alot

57 Mar 22, 2007 at 05:50 by joe morgan

i have a question about uploading. if i upload a lot will it increase my downlaod rate and in way?

58 Mar 22, 2007 at 05:51 by joe morgan

i meant in any way***

59 Mar 22, 2007 at 21:59 by mitch

i use bitlord is der anyway 2 get beter speeds on dat
am only getin dload speeds of 8k/bs

60 Apr 10, 2007 at 16:26 by GeneralTrue

Sharing is indeed very important but i rather go for the download speed cause uhm well.. mabye CAUSE I`M DOWNLOADING SOMETHING? HELLLLLLLLL..

61 May 12, 2007 at 05:46 by braden

Ok i need help if someone could configure everything for me becuase it still won’t work it would be apprectiated i have a download speed of 4017kb and an upload of 412kb

62 Jun 03, 2007 at 21:11 by ang

have my download and upload set on no limit but downloading torrents very slow sometimes can take 2 days what should i have them set on new to all this

63 Sep 05, 2007 at 21:18 by none

i always just set my upload to half of what it is untill iv finished downloading then put it up untill seeded 1:1 seems to work fine so for those that are to lazy to do math just cap the upload speed at half of what it is, so 40kbps set it too 20kbps untill you have 100% of the file then bummp it up

64 Oct 16, 2007 at 07:13 by taltos

just follow the formula it will boost your download significantly after you finish - remove the cap in upload speed to maintain your ratio

65 Dec 04, 2007 at 02:39 by Mr. Math

[quote comment="12089"]Can anyone give me the formula to work this problem. Downloading a 5 MB file from the Internet, download speed is 300 kbps, how long will it take to download the files? Show work.

Thank.
basin[/quote]

(5*1024)(1/(300/8))
result in seconds

66 Dec 06, 2007 at 08:32 by Anonymous

Good but fucks!!!!!!!!!

67 Dec 19, 2007 at 02:19 by the magic pigeon

My speed doubled thanks to this ^^

68 Dec 31, 2007 at 23:17 by ratogames

Isso é uma palhaçada!

69 Jan 17, 2008 at 03:40 by teddy

I’ve got good speed on the strongvpn.com. Hope it will help…

70 Feb 02, 2008 at 13:27 by mclovin'

Thank you so much for these tips!

I had manually set the bandwidth previously but still experienced abysmal speeds.

Once I switched the default ports my speeds jumped from 7.5 kiB down & 3.5 kiB up to 125 kiB down 45 kiB up.

ISP throttling ftl :(

71 Feb 05, 2008 at 21:19 by Rich

Whoa..I saw that date was Feb 5th and thought this was posted today (seeing how today is Feb 5th) little did I know its 2 years later..

72 Mar 06, 2008 at 03:42 by ObscureLight

The TCPOptimzer is a very bad tool when i used it, it reduced my dl speed by half when i took the test good thing it creates backups that i used

73 Mar 22, 2008 at 07:11 by Ferchu

You are a genius Ernesto, you solved my torrent problems :D. Thanks so much

Pages: « 1 2 [3] 4 » Show All

Responses are closed

All remaining responses will continue to be archived. Use the TorrentFreak forums if you want to discuss something.