Jump to content

µTorrent 2.0.2 released


Firon

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

Link to comment
Share on other sites

  • Replies 406
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
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

Link to comment
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. :(

Link to comment
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.

Link to comment
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...)

Link to comment
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...

Link to comment
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

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...