Archived

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

Firon

µTorrent 2.0.2 released

Recommended Posts

Hello.

I've noticed since several builds that with Windows 7 (32bits) (don't know with others OS), when I reboot, I launch Utorrent, the columns are reseted to original position and no longer remembered. I have a big screen 1920*1080, of course i take advantage to display longer name for torrents, so I move what is aftert the Name column:

# | Size | Done | Status | Seeds | Peers | etc...

As the problems still occurs with the latest build, I tell you.

Share this post


Link to post
Share on other sites

Make sure to shut down µTorrent manually. Sometimes Windows kills uT before it actually shuts down when you reboot.

Share this post


Link to post
Share on other sites

When I close uTorrent, it is still in the task manager (even after several hours) and Windows won't let me End Process on it, telling me: "The operation could not be completed. Access denied." Running Task Manager as Administrator makes no difference. I've found threads on this problem (example here: http://www.utorrent.com/forum/viewtopic.php?id=68718 ) I am running Windows 7 64bit and using the latest 2.0.1 RC1 build 18833.

I am not using peerblock or a firewall, only a utorrent ipfilter list

HijackThis log: http://pastebin.com/n6qGYMMk

Can this please be addressed before final?

Share this post


Link to post
Share on other sites

We basically don't know why this happens (no one here can reproduce it). It appears to be an OS bug triggered by using UDP sockets.

Could you create a dump for me? In the Task Manager, go to Processes and right click on utorrent.exe, then choose "Create Dump File". Compress it, then upload it to www.mediafire.com and email it to me. firon at utorrent.com

Share this post


Link to post
Share on other sites

can I safely disable UPnP port mapping if I manually forward a port through my router without it affecting anything? And I will try to create a dump later tonight before doing so.

Share this post


Link to post
Share on other sites

Unspecified revs of the stable means one thing: toolbar changes. That's why we don't bother autoupdating to it or posting a changelog.

Share this post


Link to post
Share on other sites
[10:22] <alus> anyway, set net.utp_dynamic_packet_size to false, and it will always use full-sized packets when you send

[10:22] <_rafi_> it doesn't

[10:23] <alus> net.utp_dynamic_packet_size is broken?

[10:23] <_rafi_> ... you can call it broken

[10:24] <alus> if you set net.utp_dynamic_packet_size to false, it should not adjust the packet size

[10:24] <_rafi_> it does

[10:24] <_rafi_> (when the limiter is on!)

[10:24] <alus> are you saying that doesn't work?

[10:24] <_rafi_> yes

[10:24] <alus> let me look

[10:25] <alus> oh, hmmm

...

Can you please fix this release so that the sent packet size will not change when net.utp_dynamic_packet_size = false and there is a set upload speed limit (as I see was the intention) ?

thanks

Share this post


Link to post
Share on other sites
Can you please fix this release so that the sent packet size will not change when net.utp_dynamic_packet_size = false and there is a set upload speed limit (as I see was the intention) ?

thanks

The behavior you are observing is a side-effect of limiting your rate when the underlying connection is very fast. This is not a bug with net.utp_dynamic_packet_size but an effect of our Nagle implementation: http://en.wikipedia.org/wiki/Nagle's_algorithm

This is *not* uTP "changing" the packet size. The same occurs with TCP if you have only written a small amount of data and the Nagle time limit (200ms on Windows) is exceeded. So if you're sending at <=7.5kB/s with TCP you will see less than full sized packets, (or higher if you have tuned Nagle like some articles tell you to http://smallvoid.com/article/winnt-nagle-algorithm.html ). You're sending (according to what you told me) at 20kB/s, which is not far off. Our Nagle target is different, because if uTP waited 200ms before sending an incomplete packet (including an ACK for data from the other direction) it would have not be able to react to delay on the order of 100ms, which is the latency target.

Share this post


Link to post
Share on other sites

I've double-checked - it's very simple: TCP has no overhead issues @ 20K speed limit. uTP does. Any setting (Nagle related or some other) that can help make the two - more or less similar - will be welcomed.

Share this post


Link to post
Share on other sites
Our Nagle target is different, because if uTP waited 200ms before sending an incomplete packet (including an ACK for data from the other direction) it would have not be able to react to delay on the order of 100ms, which is the latency target.

How many delay samples per second does uTP need to do it's congestion control efficiently... Does it really need delay measurements for every packet?.. Maybe it can send "small" (measurement) packets only sometimes (e.g. every 10th or every second) and send MTU-sized packets most of the time?.. Keyword: sampling interval

ISPs, along with online gamers and VoIP users, are really angry on current implementation of uTP...

Our ISP started to block uTP traffic after recieving complaints (high ping and packet loss) from online gamers...

Share this post


Link to post
Share on other sites

What does this mean?

[2010-04-09 10:21:58] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:121907

[2010-04-09 10:21:58] ReadFile error: Path\FileName.Ext:1077936128:4194304:4194304:3

[2010-04-09 10:22:14] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:113258

[2010-04-09 10:22:14] ReadFile error: Path\FileName.Ext:1079480517:4194304:4194304:3

[2010-04-09 10:22:31] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:89854

[2010-04-09 10:22:31] ReadFile error: Path\FileName.Ext:1076624396:4194304:4194304:3

[2010-04-09 10:22:48] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:22053

[2010-04-09 10:22:48] ReadFile error: Path\FileName.Ext:1078885752:4194304:4194304:3

[2010-04-09 10:23:03] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:100802

[2010-04-09 10:23:03] ReadFile error: Path\FileName.Ext:1082028446:4194304:4194304:3

[2010-04-09 10:23:20] IO Error:1168 line:396 align:-99 pos:-99 count:131072 actual:6690

[2010-04-09 10:23:20] ReadFile error: Path\FileName.Ext:1079503150:4194304:4194304:3

Files open and play fine by the way.

This happened twice in a row when I tried to force a recheck of the files.

Share this post


Link to post
Share on other sites
Our Nagle target is different, because if uTP waited 200ms before sending an incomplete packet (including an ACK for data from the other direction) it would have not be able to react to delay on the order of 100ms, which is the latency target.

How many delay samples per second does uTP need to do it's congestion control efficiently... Does it really need delay measurements for every packet?.. Maybe it can send "small" (measurement) packets only sometimes (e.g. every 10th or every second) and send MTU-sized packets most of the time?.. Keyword: sampling interval

ISPs, along with online gamers and VoIP users, are really angry on current implementation of uTP...

Our ISP started to block uTP traffic after recieving complaints (high ping and packet loss) from online gamers...

Delay measurement isn't done with additional packets. It isn't sending measurement packets ever. The measurement delay is done WITH data packets (using the timestamp in the packet).

You know, if you actually read the uTP spec, you'd know this.

Share this post


Link to post
Share on other sites
-- 2010-04-07: Version 2.1 (build 18936)

...

- Change: change default uTP packet size to 600 bytes

A step in the right direction ... :) can you back port it to 2.01 ? and see that it is obeyed also when using an UL speed limit ?

Thank you

Share this post


Link to post
Share on other sites

2.01 ? isn't it only a default value for a single advanced setting that was changed ? it's exactly 5 sec to change, and a very important & useful change. why not back-port it ?

Share this post


Link to post
Share on other sites

Oh, er, nevermind. You were quoting trunk's changelog...

yeah, we already made the change for 2.0.1, just haven't made a new build yet. :)

Share this post


Link to post
Share on other sites
Delay measurement isn't done with additional packets. It isn't sending measurement packets ever. The measurement delay is done WITH data packets (using the timestamp in the packet).

You know, if you actually read the uTP spec, you'd know this.

Ofcourse I know that... You just missed what I was trying to say...

To make measurements precise enough uTP has to keep DATA packets smaller... But that's not good if you make EVERY AND ALL data packets smaller to do those measurements...

Read my post again, keep in ming that those I call "measurement packets" are actually DATA packets small enough to do precise delay measurements and all other packets are DATA packets large enough (MTU) to make overhead smaller...

PS: This forum is strange, Where's "quote" button?.. Where's BBcode editor or RichText editor?.. I have only nacked textfield to write my post and I have to do all BBCode formatting manually...

Share this post


Link to post
Share on other sites

Just one question:

Is the upload speed correct on the new release, or does it still hang somewhere of 90% of the set upload speed? Dunno why, but this leads to worster download speed even if the upload speed is set to higher level (ec. 65kt/s so the real upload speed would be something like 57kt/s).

Other than that, you're doing great job! http://torrentfreak.com/utorrent-download-speeds-beat-vuze-by-16-100607/

Share this post


Link to post
Share on other sites
µTorrent 2.0.1 RC1 (build 18973)When I close uTorrent, it is still in the task manager (even after several hours) and Windows won't let me End Process on it, telling me: "The operation could not be completed. Access denied." Running Task Manager as Administrator makes no difference. I've found threads on this problem (example here: http://www.utorrent.com/forum/viewtopic.php?id=68718 ) I am running Windows 7 64bit and using the latest 2.0.1 RC1 build 18833.

I am not using peerblock or a firewall, only a utorrent ipfilter list

HijackThis log: http://pastebin.com/n6qGYMMk

Can this please be addressed before final?

I have the same problem since first's releases of version 2.0.

I still use version 1.8.5 because that.

I've seen some users complaining about this, but nobody show interest.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.