Archived

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

Firon

µTorrent 2.0.2 released

Recommended Posts

Whassup :

Is the upload speed correct on the new release...

As far as I can see - it is correct, IF you count in the overhead.

Though, the seeding overhead is still huge with uTP. With low upload connections you can get to up-to 35% overhead!

Here is what I see (RC1 build 18973):

ulutp.th.png

And the reason: still much smaller packets are being used by uTP:

TCP uTP

(87% large packets) (32% large packets)

ultcpsizes.th.png ulutpsizes.th.png

Other small issues:

* "send to player" - should be off the graph legend

* RSS -> "all feeds" is still lacking the "disable" menu item

Share this post


Link to post
Share on other sites

When I upload to the Internet (for example, with a browser) and at the same time download/seed with uT (using uTP) - it seems that uT stops DLing/seeding completely! :(

I thought uT should co-exist nicely with other apps under congestion conditions...

http://img685.imageshack.us/img685/300/utcong1.png

http://img697.imageshack.us/img697/2372/utcong2.png

utcong3.th.png

http://img685.imageshack.us/img685/3263/utcong3.png

Share this post


Link to post
Share on other sites

@rafi

i was wondering the same thing why my DL/UL drop so much after i update from 2.0 to 2.0.1 or 2.1.

when i playing online games, uT just drop to constant below 10kB/s on my 512kbps connection, sometime even constant below 2kB/s until i close my games. this problems wasnt there when i alpha and beta testing 2.0

Share this post


Link to post
Share on other sites

Oh noes! Not again. I thought we were past this. :-(

[2010-04-12 21:55:12]  ReadFile error:  <redacted>:22729015296:16384:16384:16

Share this post


Link to post
Share on other sites

With uTP disabled (Enable Bandwidth Management unchecked), I'm seeing 40-50% overhead, as reported on the status bar. That is, for example U [50kB] 25kB/s O: 22kB/s. How can this be? Overhead should be more on the order of 10%. Win7.

Share this post


Link to post
Share on other sites

If you're downloading, downloading generates significant overhead. It's the nature of how TCP and UDP work.

Share this post


Link to post
Share on other sites

Yes, I do. I was only dl'g at about .5 MB/s though. I know from past versions of uT and other dl'g, however, that overhead is nowhere near this high. .5MB/s wouldn't even equate to 10KB/s UL overhead before v2.01.

Share this post


Link to post
Share on other sites
[2010-04-13 00:17:33]  IO Error:1168 line:396 align:-99 pos:-99 count:112000 actual:1602[2010-04-13 00:17:33]  ReadFile error: cctibfs.zip:0:112000:112000:3[2010-04-13 01:07:40]  ReadFile error: Season 4\<redact> - Hope and Glory.avi:26665287680:16384:16384:16[2010-04-13 06:57:10]  IO Error:1168 line:396 align:-99 pos:-99 count:112000 actual:1602[2010-04-13 06:57:10]  ReadFile error: cctibfs.zip:0:112000:112000:3[2010-04-13 06:58:31]  IO Error:1168 line:396 align:-99 pos:-99 count:112000 actual:1602[2010-04-13 06:58:31]  ReadFile error: cctibfs.zip:0:112000:112000:3[2010-04-13 06:59:22]  IO Error:1168 line:396 align:-99 pos:-99 count:112000 actual:1602[2010-04-13 06:59:22]  ReadFile error: cctibfs.zip:0:112000:112000:3

More element not found. :(

Share this post


Link to post
Share on other sites

I don't get it then. Since when is there more (or at least equal) overhead as compared to actual upload? I've done more testing now, and when dl'g is at its most active, around 1MB/s, overhead actually dwarfs ul (out of 50KB/s, overhead hangs at around 80-90%, leaving almost nothing for actual ul). If I increase to 100KB/s, overhead doesn't drop below about 80%.

Remember that I don't even have uTP enabled. Rafi, above, expressed surprise that he saw a mere 35% overhead *with* it.

It used to be that overhead was in the minority. In past threads, I've read of "5% ACK" back when we were discussing the effects of enabling/disabling net.calc_overhead. Now it's so much higher that DLs are obviously affected.

Share this post


Link to post
Share on other sites

I don't follow you. In TCP you should expect 5% oh, that is ~50k UL for 1M DL. It`s the acks. whatever is the leftover to your UL limit or connection bndwidth if towards the real upload. isn't this what you are actually describing?

with uTP - 35% (when seeding or abit less when downloading at limitted rate - is much more then in tcp, and I don't think it's worth the congestion management (yet to be seen...)

Share this post


Link to post
Share on other sites

I feel a bit of misunderstanding here... A lot of people DO NOT understand what the overhead is... I'm sure most of them think that overhead should be ZERO in the very ideal case, and any high number means simply "uTorrent behaves bad and can't use the full potential of the connection"... It'll be better to hide actual overhead numbers somewhere and not display them in the main window...

UPD:

The simple rule: NEVER set your UL limit less than 10% of your DL limit and vice versa...

Share this post


Link to post
Share on other sites

µRemote 2.3.2 dodsn´t work with µtorrent build 18973 it worked fine in build 18833

this is the error i get from µRemote's log

--> Message:

The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

--> StackTrace:

at System.Net.HttpWebRequest.GetResponse()

at uRemote.Connection.GetWebResponse(String pURL, String pUsername, String pPassword, String pDomain)

--> Data:

System.Collections.ListDictionaryInternal

--> Error Code:

Connection.cs:186

Share this post


Link to post
Share on other sites

if utorrent broke uremote im not going to write in the uremote tread.

the fault lies in utorrent 18973 as build 18833 works fine

Share this post


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