Ideal settings for 20/1Mb connection?

[camillesge]

I have a particularly asynchronous connection, with 20Mb download and 1Mb up. Sounds like a leecher excuse, but that's just how it is in Switzerland (see http://www.swisscom.ch/res/internet/dsl/index.htm?languageId=en).

As a result, I've tried setting my speed to xx/1Mbit (which sets a 92KB/s upload cap), but don't seem to be getting good download speeds unless I also set my upload cap to 640Kb/s (60KB/s).

I'm trying to understand why this is the case. Could it be that, given my huge down/up speed difference, the ACK packets I send take up a considerable portion of my upload (http://en.wikipedia.org/wiki/Acknowledgment_code)? :|

Is anyone else in a situation, and has anyone found a "sweet spot" to optimally use their low upload connection? Thanks for any tips!

[jewelisheaven]

I'd start @ half your rate, which would be 45 or so. Then increase @ 5 KiBps for every test period. Be sure you're uploading at the limit, and download say the http://slackware.com/torrents/ cd. You only need to run it for a minute or two. But you'll see where your sweet spot is as soon as download plummets. It's possible 90 is just too much for your speedy download

My guess, you'll see download plummet ~ 78-82

[Phily]

Hi,

I have exactly the same connection as camillesge (20/1) but my problem is the download speed. It won't go above ~1.4 Mb.

Here are a few settings:

PS: Upload is (while not downloading) on 110 kb/s constant (using 1.8 beta).

Thx for your answers!

[rafi]

camillesge:

I'm trying to understand why this is the case. Could it be that, given my huge down/up speed difference, the ACK packets I send take up a considerable portion of my upload (http://en.wikipedia.org/wiki/Acknowledgment_code)?

Is anyone else in a situation, and has anyone found a "sweet spot" to optimally use their low upload connection?

exactly... I noticed it too... and that's why "we" invented a new "advanced" control flag called net.calc_overhead, so not to need to play around with any sweetspots...

Try it out on the latest beta, and post back your feedback. Your actual seeding related UL will probably low itself to ~0 when you are using the full 20M due to the ~5% ACK overhead. It will be interesting to hear your (& Phily's) results.

Too bad they chose not to set this flag to true by default...

ps:

In your place, I would change my connection to one that has at least 1:10 UL/DL ratio...

[jewelisheaven]

.2%

[camillesge]

Thanks for the helpful replies guys. I've been testing the 10093 build rafi suggested with net.calc_overhead=true and no upload cap, with the torrents jewelisheaven linked. Like Phily, I find that my rates are limited to 1.6MB/s down and 110KB/s up, although I would usually hit 2.1MB/s in 1.7.7 with the 60kb/s upload cap.

Still, 1.6MB/s is more than fast enough for me; most of the torrents I download aren't as well seeded as the Slackware torrents, so I usually hover around 300KB/s down. At any rate, I'm just glad I'm able to upload a bit more.

About this ACK and net.calc_overhead business, it'd be interesting to know whether ACK rates are a fraction of the download rate (either 5% or .2% as rafi and jewlisheaven said) or whether it can vary (i.e. 0.05%, 1%, 10%, +20%). If it does vary, does the client monitor this? I guess it's not that relevant to my connection settings issue, but I'm still quite curious. I find it awesome that overhead is being taken into consideration, instead of letting connections get blindly bogged down.

Either way, a big thanks for the help here. I had been too nervous to use the beta up to now, but it seems quite stable!

[rafi]

yes, it is proportional + the client will take it into account if this flag is enabled. You should limit your upload to less then 80% of your max UL and then (in theory) with this flag enabled - you should reach your max download (with a "good" torrent). Can you test this ?

[jewelisheaven]

The only way I've seen the overhead greater than even 1% of download is with high peer churn rate (high max halfopen high peer concurrent connections count)... the option rafi championed and is still not happy with attempts to keep ALL data output to your limit. If you don't set one... that's the first thing which needs to change. uT does not work well with unlimited upload especially on something like 1Mbit or below. It will continually try to exceed your upload cap causing bubbles in an otherwise-horizontal upload graph (if you set the upload cap then uT will show as being @ that limit 90% of the time).

[Phily]

Hi, thanks for your advice!

I'm using 1.8 10093 now and changed net.calc_overhead to "true".

Sadly this didn't change the positive way. Now I reach less dl speed and I upload to the peers (seeds) who already got 100%.

I'll let the screenshots talk for itself:

All torrents except the one show in the pic have been stopped.

Net.calc_overhead "True"

Just a few seconds later

Net.calc_overhead "False"

See the difference?

Thanks in advance for your comments!

/E

Just tried again on another torrent which is way bigger than the OO.torrents.

Results:

"true", slightly faster ~5%, using about 50% of the upload capacity on the torrent but it isn't really uploading anything at all.

"false" slightly slower, only using a few kb/s upload (normal).

[rafi]

The UL you see when set to "ture" is now not all actual data but overhead too. I would try to lower the UL limit from 110 to 80-90. You can doublecheck your speed with regular HTTP download. With good torrents - it should be the same. If both do not max your connection speed - now depends on your tuning of your TCP parameters in Windows.

[camillesge]

OK, did some more tests like rafi said. This test is with the same torrent (http://slackware.com/torrents/slackware-12.1-install-d1.torrent) every time, and restarting the client between each download.

Upload cap // Download result

==net.calc_overhead true==

60KB/s (my usual cap with which I get best results in v1.7.7) // ~1.4MB/s

92KB/s (default cap for xx/1Mbit in Speed Guide) // ~1.6MB/s (occasional 2-3 second peaks at 1.8MB/s)

100KB/s (just a nice round number )// ~1.6MB/s (occasional 2-3 second peaks at 1.8MB/s)

==net.calc_overhead false==

60KB/s // ~2.5MB/s (seriously)

92KB/s // ~2.5MB/s (seriously!)

100KB/s // ~2.5MB/s

--

The results seemed strange to me, so I also tried enabling and disabling net.calc_overhead during a download. Almost immediately (about 5 seconds), the speed would drop to 1.6MB/s when set to true, and jump back up to 2.5MB/s when set to false.

For reference: a recent speedtest.net result: 19890Kb/s down and 1150Kb/s up.

[rafi]

did you, by any chance, try measure with netmeter too ? to see is there is a display issue ?

http://www.metal-machine.de/readerror/

Disabling "peer exchange" for this torrent may also be worth a try ...

oh, and I would test with: http://slackware.com/torrents/slackware-12.1-install-dvd.torrent that has more sources...

[jewelisheaven]

2.5 is exactly maxing 20 Mbit down... that seems like it must be bursty... was it sustained, i.e. flat line?

[smileyc]

net.calc? what is this and how is it accessed ?

[Firon]

It's a new option in the 1.8 betas to estimate TCP overhead.

[smileyc]

Ty for the prompt reply, I have the 1.8 beta but have to admit being non the wiser, for instance how do i set net.calc to true or false and what are the benefits of either state?

[jewelisheaven]

Ctrl-P -> Advanced net.calc_overhead , default FALSE, change to true. No benefit. really. It attempts to keep all traffic at your limit. It's useful in cases where your upload routinely goes over due to bad settings high peer churn or high overhead due to fast transfer speeds.

[Phily]

Another test, result: even more distracted :/

rss grabbed a new release and I just happend to check µtorrent... what did I see?

7 seeds, downspeed 2.1 mb/s, new record (net.calc_overhead "false")

Before that I did try a few very very well seeded torrents (690 seeders [many seedboxes and sweds], 0-3 leechers). Actually ~60 connected seeds, downspeed still not going above 1.4-1.5 mb/s.

And yes, i reach my full 20 mbit down on ftp/http downloads and yes no display error in µtorrent.

Any more suggestions, I'm really thankful for everything you got!

[jewelisheaven]

It's limited by the peers then. :/

[rafi]

did you see the same measured on netmeter ? did disabling Peer exchange effected this ?

[Phily]

Actually I'm not using netmeter, I double checked it with my real time monitoring interface of my wrt54gl router, tomato firmware (which is very accurate).

Concerning peer exchange, didn't change anything but the torrent with 2.1 mb/s doesn't allow peer exchange.

Imho peer exchange doesn't do anything to my speed, the OpenOffice torrents allow Peer exchange and have many Seeders --> ~1.4mb/s dl

Private torrents, no peer exchange, many seeders --> ~1.4 mb/s dl

Private torrents, no peer exchange, few seeders --> ~ 2.1 mb/s (did only occour once till now)

[Greg Hazel]

OK, did some more tests like rafi said. This test is with the same torrent (http://slackware.com/torrents/slackware-12.1-install-d1.torrent) every time, and restarting the client between each download.

Upload cap // Download result

==net.calc_overhead true==

60KB/s (my usual cap with which I get best results in v1.7.7) // ~1.4MB/s

92KB/s (default cap for xx/1Mbit in Speed Guide) // ~1.6MB/s (occasional 2-3 second peaks at 1.8MB/s)

100KB/s (just a nice round number )// ~1.6MB/s (occasional 2-3 second peaks at 1.8MB/s)

==net.calc_overhead false==

60KB/s // ~2.5MB/s (seriously)

92KB/s // ~2.5MB/s (seriously!)

100KB/s // ~2.5MB/s

--

The results seemed strange to me, so I also tried enabling and disabling net.calc_overhead during a download. Almost immediately (about 5 seconds), the speed would drop to 1.6MB/s when set to true, and jump back up to 2.5MB/s when set to false.

For reference: a recent speedtest.net result: 19890Kb/s down and 1150Kb/s up.

At 1.4MB/s, the ACK overhead is approximately 72kB/s. At 1.8MB/s it's 92kB/s. What's probably happening here is that uTorrent is limiting your upload to peers - including piece requests - because your download overhead is eating all of the upload bandwidth. To download at 1.4MB/s you need at least 1.2kB/s upload worth of piece requests, not to mention have messages, choke/interested state, PEX, and connections.

In your calc_overhead false example, your upload limit is 60kB/s so downloading at 2.5MB/s you're really trying to upload at about 191kB/s - above your line capacity. Do you ever hit 60kB/s up when downloading at 2.5MB/s? What kind of internet connection is this?

Try using net.calc_overhead set to true, and an upload rate limit near your line capacity - say 140kB/s.

[Phily]

To make it clear for me, if I increase my upload speed (inet connection) from 1mbit up to 2mbit, I'll be able to download faster?

[rafi]

http://forum.utorrent.com/viewtopic.php?pid=327778#p327778 :

rafi:

ps:

In your place, I would change my connection to one that has at least 1:10 UL/DL ratio...

But first, try out what alus suggested ...

[Phily]

Did what alus recommended but the result didn't bring any real improvements.

Net.calc_overhead "true", ul limit: 140 --> dl between 1.5-1.7 mb/s. Its a little bit faster but eg surfing while downloading is now nearly impossible.

If there aren't any other things I could do, I'll report back when my upgrading to 20/2 is done.

thx for your help guys!