thanks for the advises – i´ve tried it and it improoved my download speed immedeately !

greeting
zeroKool

http://infinite-source.de/az/az-calc.html

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 :(

Thank.
basin[/quote]

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

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,

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,

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.

Thank.
basin

dude i love ure tips it helped me out a lot.

Lets say I just want the 277kb .NFO file for a description of Devil May Cry from eastgame before I download it.

I was connected for 35mins and never got NFO file all it did was max my upload bandwidth which in turn killed my downloads with time-outs.
How can I be uploading at 50KB/s when I havent even got 1kbs of the text file? There were 50 Seeds!(All of which were unconnectable) and 2000 leechers.

Is my computer sending packets to every leecher trying to connect? I checked bandwidth monitor and sure enough my upload speed was maxed but never did get the f*kin NFO file.

Just to let you know I have not had any problem getting torrents for last 3 months but this particular one was weird!!!!!!!!!!!!!

I was at 0.0% download kbs but uploading at max of my bandwidth with nothing to upload!!!!!!!!!!!!!!!!

or other downloads/uploads going on.

What’s the fks the deal?

Great work!

THANK YOU!!!!

OK first off most every ones download speed is faster then their and every one else’s upload speeds. There for when using a torrent it’s easy for your upload pipe to get maxed out. The problem with this is that with TCP/IP protocol when your computer receives a packet of data your computer has to send a receipt packet back to the sender. This packet tells the sending computer that the data packet was received and it can send the next one, BUT if your computer is using all of your upload bandwidth sending packets of data to other leechers your receipt packet doesn’t get sent right away and the sender just waits or worse times-out. Slowing the whole process. Which in turns slows you from becoming a seed instead of a leecher and we all like seeds more then leechers.

————————————

Maybe I don’t understand.

For ex:

“so if your maximum upload speed is 128 kb/s, the optimal upload rate is

128 / 8 * 85% = 13.6″

In other words, if people have a capacity to seed at 128 kb/s, then they are expected lower their upload to 13.6.

That’s the why I understood it.

—————————————-

128kbs / 8 = 13kB/s

speeds are often listed in bits/second, but really we’re measuring our speeds in bytes/second in all client configurations, download windows, and everything in the history of the universe

bits are not bytes