µTorrent 1.9 alpha 15380

I am making the seed of a torrent, the problem is that there is a constant download of 6 Kb/s, while with the 1.8.1 it is all right

Yes, it is normally limited to 180KiB/s.. I set it to automatic and it went to 40KiB/s, which is much too low - and yet I can't do -anything- with my internet anymore while it's running. This actually happens even if I turn µTP off, (or it did in the first build I tried.. I'm a bit hesitant to do more testing unless required) so the problem is very strange.

demo of the issue with RSS releases view disapearing when you click download and then loosing focus on "all feeds" ... :

http://www.mediafire.com/?mkmdnryzwwg

rafi,

If you've got 250 connections at once, uTP trying to rate-limit might be failing due to too many connections to manage. Does the same thing happen with 50 total connections?

XangXing,

Under uTorrent v1.9, the advanced setting net.calc_overhead defaults to TRUE. So uTorrent is estimating how much download bandwidth is used to reach your current upload speed.

Ver Greeneyes,

Try disabling DHT, LPD, UPnP, NAT-PMP, and Resolve IPs.

Also reduce bt.connect_speed and net.max_halfopen to 4 or less.

2nd link in my signature for other settings...

250 is not many, and it should handle them well. PEXing is the issue...

250 is a lot for only 22 KB/sec total upload speed.

Since TCP is now partly replaced with UDP - overhead might even be reduced, and the overhead calculation/reduction should easily account for more peers.

As I see it there are two things to try an do (to adjust the overshoot):

A. Find the problem in the math/calculation of overhead for UDP peers

B. Attend to the PEX issue - by simply give an advanced control-setup to the MAX # of PEX peers the user like to involve. Since we can eliminate PEX altogether (as I do now...) I don't see any harm in this.

TCP and UDP overhead are considered separately. Also, the UDP overhead calculation should be more accurate, not less.

I'm not saying it's not accurate, just that it has some error... like a + instead of a - ... just kidding... the bottom line - it's overshooting the limit . Just set to a low limit (~12K) use netmeter and see for yourself.

how about the user max PEXed peers setup ? can you add it in ? look at the 3rd graph here: http://forum.utorrent.com/viewtopic.php?pid=383827#p383827

edit:

the problem can be unrelated directly to the UDP OH , but to the way it's taken into account in comparing to the speed-graph/limit

250 is not many, and it should handle them well. PEXing is the issue...

You need a decent connection for that kind of number. 22KB/s isn't. With that little upload, you need to be careful and meticulous with your settings. I wouldn't even turn on PEX. Just wastes bandwidth for little gain (PEX is overrated IMHO).

200/20KB or 300/30 are typical connections where I live. PEX is now on by default, I think. That's why I suggested the possibility to have a setup/limit for the # of peers for PEX (maybe in the same menu we have the 'enable' for it today). It's better then disabling it altogether. I would also make it so it is auto-set in the 'speed guide' menu where you define your upload. A proper value would probably be around 50 for every 20K upload (and maybe default to 100) . Staggering was also considered as a solution but it seems not to work very well, maybe since the peers' list is changing and it's not so practical/easy to keep track. Though, this # can also be used for Staggering ...

Edit:

Another user option can be to auto-activate PEX ONLY in torrents that connects with below a user defined # of peers or below some global total # of connected peers.

is it just me or the new build has error on total downloaded files?

check your bottom right status bar.

Is there a project of a feature with new buttons/icons because with a full 1.8.1 skin, I got this msg:

Impossible to load skin file "tstatus.bmp": bad number of images, 16 instead of 19 (or 38)

I noticed an odd issue just this morning. I was seeding through the night, no downloads, yet it said my total downloads were nearly 131GB. That total doesn't even add up to all my downloads combined.

Just a notice. This was on build 13885

Just an impression I'm getting from the latest releases - I have a feeling that finding & keeping good peers also in cases of poor p/s ratio is faster here, and speed is also building up nice and fast (I not using PEX...). Still, I need to get some more experience with it but it looks/feels much improved and stable.

Any to my favorite feature - RSS - it was great to see progress in this last build. Keep up the good work Richard ! and be brave and do the #18 item in my list here ... http://forum.utorrent.com/viewtopic.php?pid=352646#p352646 that is turning greener and greener !

Have a marry Christmas / Hanuka all !

I'm still having this wacky issue with the download measurement with build 13885 - its measuring the downloaded data in GB instead of MB.

IPv6 is disabled via:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]

"DisabledComponents"=dword:000000ff

Yet uTorrent says IPv6 is installed on the logger tab.

If this key (check the bit order to verify that IPv6 and/or Teredo is disabled) is set than uTorrent should not report anything about IPv6 and the activate IPv6/Teredo button should be disabled too.

IPv6 is disabled via:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]

"DisabledComponents"=dword:000000ff

Yet uTorrent says IPv6 is installed on the logger tab.

If this key (check the bit order to verify that IPv6 and/or Teredo is disabled) is set than uTorrent should not report anything about IPv6 and the activate IPv6/Teredo button should be disabled too.

uTorrent reports that IPv6 is installed if "::1" resolves. It prints the Teredo address if an adapter is found with a Teredo address. uTorrent does not consider that registry setting, and will not. If you don't want IPv6 you should uninstall it from the Network Connections properties in the Control Panel.

I posted in the 1.8.1 thread, but I think that's closed so I will post again here:

I don't know if this is a bug or intended:

Set the scheduler to "seeding only" at any time slot

have some downloading torrents, some seeding torrents.

Set the Queueing to allow Maximum number of active torrent = 3, maximum number of active downloads = 3

When the scheduler is in the Full speed mode, your downloading torrents will be downloading (3 of them) all rest are queued (good)

but when the scheduler is the seeding only mode, 3 downloading torrents will be uploading, and 3 of seeding torrent will be seeding (total 6 torrent running at the same time all uploading... contradiction to settings)

Also, if you check the "Alternate upload rate when not downloading..." this does NOT take into effect when in seeding only mode.

One thing for sure its improved by leaps and bounds.

Nice work.

I wish my connection still wasn't getting reset all the time. Anyone have any suggestions? I have comcast and they just did the recent speed upgrade in my area.

All works fine for me. But speed is little bit lower then in 1.8.1

uTorrent reports that IPv6 is installed if "::1" resolves. It prints the Teredo address if an adapter is found with a Teredo address. uTorrent does not consider that registry setting, and will not. If you don't want IPv6 you should uninstall it from the Network Connections properties in the Control Panel.

It would be nice if uTorrent had an option to turn IPv6 support off. Just because someone installed IPv6 or uses it, doesn't mean they want to use it for BitTorrent. (I have it installed for testing purposes)

On topic; A question about overhead with uTP. How does it compare to normal TCP? From what I can tell, uTP creates a lot more overhead than TCP. When uploading 30KB/s to a peer, I get about 1.5KB/s back using TCP. For uTP, this is 4KB/s.

Second, uTP seems to work pretty well, if there is a large selection of peers to upload to. But the latter isn't always the case. Hance, I personally prefer TCP over uTP, but, there is no setting for this. You can choose TCP, uTP or both but the latter seems to prefer uTP over TCP. I would be nice it there was an option that prefers TCP over uTP, and only moves to uTP when it detects problems (such as ISP interference).

Also, I'm I correct in seeing that latency on the first few hops (router, cablemodem) reduce the performance of uTP, even though their may be sufficient bandwidth available to saturate the upstream?

klaus - that might be because you're likely to have more utorrent 1.8.1 (utp able) users to upload to with a larger number of peers. i cannot wait for 1.9 to be officially released. does anyone know if azureus (and others) will introduce this capability with future releases?

That'd be up to them, but uTP is intended to be an open protocol (it's just under testing at the moment, so specs aren't publicly available to others yet).