Jump to content

µTorrent 1.9 alpha 15380


Firon

Recommended Posts

"Set net.calc_overhead to false. The real upload speed will still be ~40-50 KB/sec when set to 30 KB/sec, but at least you won't have to see it then.

If your download speed wasn't so many times higher than your upload this wouldn't be happening."

How about just confirm its broken and fix it instead? :)

Upload limit should limit upload. uTorrent brakes set limits even when only seeding. I set 40 I get 45-50, I set 55 I get 60-65 and so on. In fact when I look at Wireshark IO graphs It _never_ goes below set limit, but floats 5-10KB above it with no download, and goes crazy with any download.

I get the impression somewhere down the road uTorrent dropped ACK upload from the limiting formula. I seem to remember downloading 700KB/s with upload limit set to 55KB/s and it was holding in 55-60KB/s range. Its impossible with current build as you saw, I had to set limit to 25KB/s to not exceed 55KB/s

next UDP. It obeys limits same way as TCP now so thats fixed. But :(

-All I get are 3xx bytes UDP packets from other peers, they seem to love 323 and 365 byte sizes. From pool of ~200 peers I got only ONE peer to send me >365 bytes packets. It send me twelve 1265 bytes packets. All that during 10 minutes of high traffic.

-My MTU is 1500, but somehow uTorrent kept trying to send 1506 bytes UDP packets. Most of those packets went to one specific peer. By most I mean my Utorrent send 500 1506 bytes UDP packets to one peer, 7 1506 bytes UDP packets to other and 3 to third one.

There were only 2 (two) packets in 1400-1500 range during that time. Im using wireshark filters for this :

udp && (ip.src== my.ip.is.here) && (frame.len > 1400) && (frame.len <1500)

BTW 10:1 down/up ratio is rather common for cable/adsl so I fail to see whats so weird about wanting to download at 600KB/s while uploading at 60KB/s.

Link to comment
Share on other sites

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Not only bad things should be posted...

THIS NEW 15380 JUST ROCKS!

For the first time I can get FLAT uTP full speed upload. (one torrent uploading to just one peer with 236ms "ping" latency, bt_transp = 15 & net.calc_over = false, PPPoA 4Mbit/600Kbit) :cool:

flatutpfullspeed.png

Link to comment
Share on other sites

kokobaroko:

-All I get are 3xx bytes UDP packets from other peers

sounds logical, since the modification to maximize UDP packets was only done to 1.9 and 1.8.3. Most your "other" peers are 1.8.2, that is using smaller packets.

Link to comment
Share on other sites

Well doesn't uninstalling and installing again remove the settings? Besides, I would rather leave it as is and help them resolve the issue of it not overwriting the exe, that being said, I'm not sure how long my patience not to run the new version will last :( it sounds tasty.

Link to comment
Share on other sites

This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.

Awesome feature, I have been reluctant to trying 1.9 out due to the previous ignoring of rate limits, but that has been fixed and I decided to try it.

Setting my upload to unlimited (before I limited it to 50) it varies from my max upload (100-160KB/s) to anywhere lower, giving enough bandwidth to not bog down my network.

Long story short, after running it all day at unlimited I have not noticed it running at all (in terms of browsing speed) and neither have the others on my network.

Well doesn't uninstalling and installing again remove the settings? Besides, I would rather leave it as is and help them resolve the issue of it not overwriting the exe, that being said, I'm not sure how long my patience not to run the new version will last it sounds tasty.

"Install" the new version like normal, then take the installer exe and put it in the uTorrent install directory. Rename the old .exe to something like "uTorrent.exe.bak" just incase you wish to go back to the old version. Now rename the new exe (the one you just put into the uTorrent directory) to uTorrent.exe......it should work perfectly fine, thats how I managed to install it over 1.8.3 and it is working fine ATM.

Link to comment
Share on other sites

-My MTU is 1500, but somehow uTorrent kept trying to send 1506 bytes UDP packets. Most of those packets went to one specific peer. By most I mean my Utorrent send 500 1506 bytes UDP packets to one peer, 7 1506 bytes UDP packets to other and 3 to third one.

There were only 2 (two) packets in 1400-1500 range during that time. Im using wireshark filters for this :

udp && (ip.src== my.ip.is.here) && (frame.len > 1400) && (frame.len <1500)

Can you post the wireshark capture that shows > 1500 byte packets? Also, is it easy to reproduce that?

Link to comment
Share on other sites

well, what about the opposite symptom - of only using small packets ... am I mistaken here as well ? ... or there is a logical explanation to this ? ;)

uTP uses variable packet sizes. At low speeds the packet size is small, so that we have finer grain control over how much data is in transit (often only 1 packet). When there are more packets in flight at once, we increase the packet size to reduce overhead without losing much granularity.

Link to comment
Share on other sites

Greg:

When there are more packets in flight at once, we increase the packet size to reduce over

if the end result is -~20% in DL speed under TCP @ 1.5Mbps (as you can see on the graphs in the 1.8.3 thread http://forum.utorrent.com/viewtopic.php?pid=408454#p408454 ) I think it should be further tuned. ~60-70% of the Internet subscribers here are on 1.5-2.0M speeds with 10% of that - upload .

Link to comment
Share on other sites

Hey - just grabbed the latest alpha :)

Nice to see the upload issue has been worked on to lower the ramped upload speed :D

I noticed that a lot of the UDP traffic by uTP is getting bad checksum results (Wireshark). This may just be a characteristic of UDP but i was wondering if anyone else was also seeing this? I can post the Wireshark data if needed just let me know.

Excellent Work :D

Edit: I just noticed some TCP packets have a similar issue, but the speeds don't seem to be affected.

Link to comment
Share on other sites

Just... WOW!

My ISP Recently started traffic shaping Torrent traffic (DSL in canada is pretty much all sold by Bell Canada, which has claimed the right to limit all reseller/3rd party DSL providers).

Just last week, they snuffed my torrent speed down to 25kb/s, from 800.

Thanks to 1.9 i was able to reach up to 600kb/s today, for the first time in over a week, thank you! You guys rock!

Link to comment
Share on other sites

Finally moved up to this alpha. :)

A few questions:

* I assume that "P" in the flags column means "UTP"? (update FAQ?)

* You say that UTP should work automaticall without an upload limit, yes? But how do we stop TCP connections flooding the pipe? Is "Automatic" upload speed tickbox the answer? Should I disable TCP?

* What does net.utp_target_delay do? If my latency to, say europe is >200 should I increase it?

* How does turning on calc_overhead affect the speed guide? Should the bandwidth number be increase? What about statistics dialog?

-- Thanks

(ps. It would be great if it was possible to set a "bt.auto_ul_max" so that I can prevent it setting limits higher than the connection is capable of (burst > sustained). I supose UTP makes it all irrelevant?)

Link to comment
Share on other sites

* I assume that "P" in the flags column means "UTP"? (update FAQ?)

* You say that UTP should work automaticall without an upload limit, yes? But how do we stop TCP connections flooding the pipe? Is "Automatic" upload speed tickbox the answer? Should I disable TCP?

* Looks like it, every peer in my list that supports uTP has the P flag, every peer that doesn't support it doesn't have the flag.

* Yes, setting it to Automatic dynamically changes the upload limits based on traffic.....I have ran it on Automatic seeding a few high-traffic torrents for weeks now and I have not noticed any slowdown at all....infact if I run a speed test (while its set to automatic) I get my normal down/up speeds. Its not perfect though, I have found with it on automatic I have nearly twice the ping I typically do in online games....so if your going to be gaming than impose a limit while you game (or simply pause them while you game) but on automatic you will practically never notice a difference in your internet browsing.

Link to comment
Share on other sites

I noticed that setting Unlimited upload makes it ramp up way slower than if you set hard upload limit, I guess its a price one has to pay for convenience as unlimited no longer makes the whole internet slow.

For example if I set it to 65KB/s (I got 512KBit upload) it will seed at max speed all the time no matter if I upload something or not, but if I set it to unlimited it will almost stop seeding (down to few kilobytes/s) as soon as it detects full pipe (if I start downloading something with my browser or utorrent itself).

Maybe it would be nice to have real unlimited as an additional option that would just push as much it can without looking at pipe conditions.

edit: on the other hand setting upload limit higher than actual upload pipe makes utorrent just push as much it can, so its exactly what i want.

Link to comment
Share on other sites

For anyone wondering about some of the new advanced options...

bt.ratelimit_tcp_only: Enabling this option tells µTorrent to limit the upload and download rates for TCP connections based on information received over the uTP transport rather than using static global rate limits. This option is ignored if bt.tcp_rate_control is disabled.

bt.tcp_rate_control: Enabling this option tells µTorrent to use information from the uTP transport as hints for limiting TCP transfer rates.

net.utp_target_delay: This option controls the threshold detected connection delay that, if surpassed, will cause µTorrent to throttle back on bandwidth usage. The higher this option is set, the more forgiving µTorrent will be toward connection delays, meaning that it will be less likely to throttle back on bandwidth usage. This option is interpreted in milliseconds, so please enter it as such.

I might have to double-check the definitions with the devs again, but that's what I have since I last updated my copy of the manual.

@fowl:

- Yes, "P" means uTP. The FAQ isn't updated for non-stable builds.

- Automatic upload rate limiting as implemented in 1.7.x will likely be phased out by uTP, as they perform similar functions, but who knows. At any rate, uTP provides hints to µTorrent on how it should limit TCP (see bt.tcp_rate_control).

- See above about net.utp_target_delay.

- net.calc_overhead affects nothing but rate limiting. The Speed Guide doesn't (and shouldn't) take it into account, and the overhead is not counted toward the total amount of data downloaded/uploaded.

Link to comment
Share on other sites

Automatic upload rate limiting as implemented in 1.7.x will likely be phased out by uTP, as they perform similar functions, but who knows. At any rate, uTP provides hints to µTorrent on how it should limit TCP (see bt.tcp_rate_control).

So ideally I should untick automatic and just type in 0 as the maximum upload rate? Or untick auto set a sensible rate limit and enable bt.ratelimit_tcp_only?

net.utp_target_delay: .. detected connection delay... milliseconds..

Is this round trip? If so, round trip to where? I'm on different continent to where most of the peers I'm interacting with will be located. :D

- net.calc_overhead affects nothing but rate limiting. The Speed Guide doesn't (and shouldn't) take it into account, and the overhead is not counted toward the total amount of data downloaded/uploaded.

But the speed guide includes a rate limit? Doesn't it?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...