µTorrent 1.9 alpha 15380

[kokobaroko]

something is off with upload, maybe its not counting peer exchange and DHT as traffic

I set upload limit to 40KB/s and it still saturates my 65KB connection (local peers off)

it shows 12KB/s upload on the graph while NetMeter shows saturated upload

[Greg Hazel]

Can you capture a Wireshark log of when that's happening?

[Troller]

I tested with only uTP on and problem was there with only TCP it's not but then I'm limited like hell and when I PAUSE all torrents the transfer goes on!!! it does not stop completely

[Ultima]

Pausing a torrent has never caused it to stop using bandwidth immediately. It attempts to complete whatever pieces it's in the middle of transferring before it actually stops.

[kokobaroko]

I ran wireshark with statictics IO Graph window open

When I set upload limit to 50KB/s Utorrent limits TCP upload to 50KB/s , but still uploads additional 5-15KB/s UDP. even with

bt.transp_disposition set to 5 - TCP only

so its set to 50KB max, netmeter shows 57KB, and at the same time wireshark shows 50KB TCP + 7KB UDP

green(edit, I wrote red while i was thinking green) is more less 50KB, bt.transp_disposition set to 5

[Greg Hazel]

That extra UDP traffic could be the DHT. Turn on net.calc_overhead as well, that should make uT more accurate.

[kokobaroko]

net.calc_overhead was on before

hmm, just found out peer exchange is always on, even when its not turned off in settings

anyway yes, it looks like uTorrent is not counting DHT traffic into account when limiting upload

with bt.transp_disposition = 5 and DHT off there is no UDP traffic and utorrent shows more or less accurate upload speed, so that works

now Im trying bt.transp_disposition = 255, DHT off, peer exchange off (tho its still turned on under torrent tracker status tab, maybe a bug?)

as you can see utorrent tab never hits 50KB limit, yet my upload is saturated (64KB/s, my isp limits it at ~64-75KB/s)

[Troller]

in my case now i see 92k down 280 k up in the client and my monitoring software tells that i have 140k down and 392k up !!! I'll check those things in settings tough

I only checked this so far: bt.transp_disposition

I had the net calc thing on false! by default now let"s see how that changes things

Still I have a 50-70k difference between my monitoring app shows and what utorrent!

[kokobaroko]

again about peer exchange, turning it off in settings only rworks for SEEDED torrents , those show nice "not allowed" under Tracker tab, but torrents that are downloaded show peer exchange as "working"

last screenie, 1.8.1 with DHT enabled and 50KB limit set

much less UDP even with DHT enabled and keeps nice smooth ~50KB/s .. well more like 55KB/s, but still its a lot smoother

[Troller]

in 1.81 I was unable to get the uTP to work, my issues are with the newest beta 13521 build

[Ver Greeneyes]

I've tried build 13485 but it seems to take complete control of my connection after a few minutes, making me unable to browse the web even from my laptop (both are connected to the same router). This seems to happen regardless of what I set bt.transp_disposition to (I've tried 255 and 5). µTorrent continues to function on both machines, however. (my laptop was using 1.8.1 at the time) This problem did not exist in 1.8.1. Should I try build 13520? This is not a problem I've seen mentioned here, so I'm not sure if it would help. (Also I'd rather not try 1.9 again until this problem is fixed, as I'm heavily reliant on having internet access - but if you think it'll help I'll take one for the team)

[Ultima]

Try 13520 for a few minutes (to get the logs, doing as the instructions say in the first post). More logs should help in analyzing real-world behaviors that may not have been caught in internal testing.

[Ver Greeneyes]

Here you go. I hope this isn't too big, it took a while for a pattern to emerge. Upload speeds fluctuated between ~75kiB/s and ~105kiB/s - normally I can easily do 175kiB/s. As before, browsing the web became impossible only a few minutes after starting µTorrent.

By the way after closing µTorrent, explorer.exe was using about 125MiB and maxing out a core. I kept an eye on it and watched as it slowly (very slowly) returned to ~40MiB before CPU utilisation finally dropped. This took perhaps 30 minutes, during which the system slowed to a crawl.

[arbitel]

Tested build 13485 for few days. Everything seems okay but only a few problems which are kinda annoying.

1) When bt.trans_disposition is set to 255, the uTorrent.exe tends to lag alot and the cpu usage skyrocketed. When I set it back to 0, everything went back to normal. I wonder if that makes any difference in downloading speed cause I don't really notice.. ?

2) When bt.trans_disposition is set to 255, the Tracker status keeps on showing 'updating' and I guess that is what causing the cpu usage hog. Any idea guys?

Thanks for the wonderful uTorrent.

Regards,

arbitel

[Troller]

The 13520 build instantly locked up for me with 100% cpu usage. I think something is about the new uTP protocol and with the 521 build I get cpu spikes. And even without that 50-70k that utorrent does not count as traffic somehow, it's far more better then the 1.81 version where I was totally limited to 10k upload.

[osm0sis]

Both of those are only meant to capture the traffic in logs, might explain the CPU.. 13485 is the actual current alpha still.

[Switeck]

Tested build 13485 on Win XP Pro AND Win 98SE. Both experienced freezing on exit where the exe remained in memory 5+ minutes after the GUI disappeared. (I noticed this using Process Explorer.)

I also see essentially impossible ips in Peer Lists (from right-clicking in the Peer window of an active torrent, Copy Peer List, and pasting into notepad).

I also copied this from uTorrent's LOGGER, confirming these ips are attempted:

[2008-11-29 21:22:07] 0.56.58.0:12389 [utp]: Connecting: source: T

[2008-11-29 21:22:16] 0.116.101.105:13413 [utp]: Connecting: source: T

These "appear" to originate from the tracker, but since I've used these trackers before...it seems unusual for them to only now start having trouble.

[Gonzo68]

I did install build 13485 got no crash or bug but download/upload speed went down too much and i went back to 1.8.1

I will wait until a couple of more build come up before thinking to install it back

[GTHK]

Copied this from my Logger after some RSS feed matches:

[2008-11-30 20:42:45] 灨Ɔw Download from RSS|stuff2.avi has started downloading.

[2008-11-30 22:12:48] 㬠¶w Download from RSS|stuff1.avi has started downloading.

[Simon Morris]

A comment from BitTorrent on UTP:

Firon posted already about UTP:

******

uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.

******

Just to re-iterate and offer a few more details (there's some pretty wild press reports popping up):

Firon described uTP completely accurately.

uTP is the result of a couple of years of work to try to make a Bittorrent protocol that works better on the internet.

The switch to uTP is at this point purely experimental, but the design objective (counter to some reports in the press) is actually to offer better congestion control than TCP offers, but maintain the same level of performance (speed).

Better congestion control is good for everyone – for users (VOIP, Gamers etc.) as well as for ISPs.

Same performance is what users have come to expect from their BitTorrent application – unless we can offer the same performance, then people will switch to a different BitTorrent client. (In reality we may be able to offer faster speeds too in many circumstances, but this is a byproduct and not the main objective.)

uTP is our UDP-based implementation of the BitTorrent protocol.

Normally BitTorrent is implemented on top of TCP which is the standard congestion control mechanism for the internet.

It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once "packet loss" has occurred – i.e. once the user has lost data and (probably) noticed there is a problem. The problems of TCP are fairly well known in technical circles, but it doesn't get fixed as TCP is one of those protocols that is implemented in every OS, client and server, on the internet. Co-ordinating a giant upgrade is a very long process.

Because BitTorrent publishes the world's most popular BitTorrent clients AND because these clients are talking mostly to each other (not to web servers), then we have an opportunity to detect end-to-end congestion and implement a protocol that can detect problems very quickly and throttle back accordingly so that BitTorrent doesn't slow down the internet connection and Gamers and VOIP users don't notice any problems. This is our objective.

This is great news for users of the internet and even for ISPs as it should mean that people make far more efficient use of internet bandwidth, but don't over-use it to destruction. If uTP is successful, then internet congestion due to BitTorrent protocol could become a thing of the past. Of course there are many other applications that use the internet and they may also cause congestion, but we can only control what we do. Having said that, given that some press reports suggest that BitTorrent traffic constitutes half of all traffic on the internet, our technology might have a profound impact. We're trying to do our bit to be responsible citizens on the internet.

While uTP is for now a proprietary BitTorrent protocol, we are also co-chairing an IETF group to address these issues. Hopefully that will lead to solutions that can be standardized and broadly adopted in due course.

Simon Morris

VP Product Management

BitTorrent, Inc.

[Harold]

So is there any chance that 'interested parties' will be shown how the uTP protocol works before it's a full-blown IETF standard?

[gritzko]

There are some IETF talks by Shalunov

http://shlang.com/talks/20080528-BitTorrent-position-IETF-P2P.pdf

http://shlang.com/talks/20080528-ietf-p2pi-BitTorrent-slides.pdf

The general line is that they are using their previous BitTorrent DNA developments on delay-based congestion control. DNA protocol is kinda proprietary and secret as well... but the whole stuff looks like a lightweight implementation of TCP over UDP with delay-based congestion control and probably some P4P-like topology hints in the future.

Still, declaring they wanna it be a standard and keeping it sikrit at the same time is kinda strange.

[DreadWingKnight]

I don't blame anyone for not wanting a beta product to be widespread. Until it's stabilized and fully functional, they have every right to keep is secret.

[kokobaroko]

>Better congestion control is good for everyone

before _any_ congestion control can be implemented uTorrrent must first start to count traffic correctly, currently it forgets about half the UDP packets it sends

[Harold]

Many thanks, gritzko

It doesn't say very much, but it's something

But, seeing as the actual protocol seems to be secret (and rather hard to reverse-engineer, I don't expect to pull that off before the RFC is released, unless it really takes half a year or something), is there any idea when it might be ready? Of course I'm not expecting any promisses, but it'd be nice to have some kind of idea as to when it might be ready..