Klaus_1250

<quote>I am running Windows Millennium...</quote> Not to offend you, but Windows Millennium should not be allowed on the net anymore. It is no longer supported by MS and was unsafe and unstable from day one. You can't expect software vendors to keep supporting an OS that has been EOL for years.

With default I mean all standard settings and suitable bandwidth settings.

Is there a way to disable all internal rate-limiting / automatic speed thingies? I'm having a terrible time getting uTorrent to properly fill its upload? This wasn't a problem on 1.8.x and isn't a problem on other P2P apps (eMule does it perfectly). But 1.9 sometimes seem to cap itself well below the available bandwidth. It even seems to do this for downloading. It starts of fast, but then slowly moves down and for some reason, people start snubbing me. Vuze or Halite don't seem to have this problem, not do other P2P apps. Already tried doing a clean install of uTorrent, cleaning out all files in the Application Data folder and using the default settings.

The logging builds are known to crash or produce other odd behavior. Just try 13910.

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?

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).

Saw the same actually, but I'm not sure whether it is uTorrent or the Tracker. In my case, it does update the ratio, but not as much as it should and not on all torrents. I never noticed it before, but then again, I never meticulously looked at all the numbers.

After trying out uTP some more, I can get reasonable results with it; 75-95% upstream usuage. It does seem to rely highly on the connected peers. The only way to get good results if there are one to three uTP peers which can download at 50-120KB/s (bandwidth is set at 150KB/s up). There does seem to be a periodic dip after 1min in which the upspeed falls back to 50% and then slowly (20-30sec) goes back to near maximum. Not sure, but it seems that uTorrent itself is behaving like this. It also appears that uTP works great for some peers (which cannot seem to download at all with TCP), but performance decreases with some peers which could reliably download through TCP at higher but limited speeds than uTP. I have no clue how uTorrent measures line useage / latency / etc. Doesn't seem pings with small TTL like cFos, NAFC like emule?

Nope. Network us pretty clean. Only thing I use that is UDP is Hamachi but that is idle for 99% of the time, only use it for RDP at specific times. Router traffic daemon also shows that there is hardly any traffic unless I fire up uTorrent or anything else network intensive. The only thing I can see that might be related is cFosSpeed. OTOH, it gives the same priority to uTorrent TCP-packets as uTorrent UDP packets (L7 is off, so packets priority is based on processname). I also use Comodo Firewall, but the firewall part is disabled. Ping times for Google.com using TCP only: Ping statistics for 208.69.34.230: Packets: Sent = 199, Received = 196, Lost = 3 (1% loss), Approximate round trip times in milli-seconds: Minimum = 18ms, Maximum = 75ms, Average = 38ms Ping times for Google.com using uTP: Ping statistics for 208.69.34.230: Packets: Sent = 304, Received = 303, Lost = 1 (0% loss), Approximate round trip times in milli-seconds: Minimum = 18ms, Maximum = 149ms, Average = 27ms I should point out that the above isn't representative for anything. Using TCP, my download was 400KB/s down and 140KB/s up. Using uTP 40KB/s down, 4KB/s up (and I waited longer for speeds to pick up). I also use Hamachi from time to time for Remote Desktop Connection. It uses UDP (tunnels) as well, but I 've never had an issue with that. AFAIK, there is either something wrong with uTorrent (the logging build freezes uTorrent, hint?) or something with my Windows XP settings. I've tweaked the TCP parameters, but I don't remember seeing anything about UDP ever?

No. I still can't use any of the logging builds, locks up uTorrent completely within seconds.

@Mojo: you can't use TCP up- and download like that without Traffic Shaping. Your TCP-ACK's will het delayed by the upload-traffic, hence you need to prioritize those. That you can use 90% download and 90% upload among different apps simultanously.

13520 stalls (CPU goes through the roof) with UDP. Secondly, I'n not to sure if it is smart to allow uTP with 1.8.1 by default. I doubt any 1.8.1 user knows uTP will be used if possible and UDP can cause havoc on crappy routers and modems (which there are a lot of) resulting on poor internet performance and no telephone if the providers offers VOIP.

Well, from the first glance, it doesn't seem to work OK. As soon as I start downloading something, upload performance drops like brick in a vacuum. With 1.8.1 I can upload 145KB/s and download 700KB/s, 1.9 falls to 40KB/s at a 200KB/s download Using mostl uTP connections to uT and BT). Looking at the internal graph, the upload mirrors the download. But I can't tell whether this is 1.9 or the uTP-implmentation in uT1.8.1/BT6.1.1. [edit]just tested 1.9 with UDP connections blocked. 900KB/s down (limited) and 130KB/s up. Seems it fixes a bug in 1.8.1 as well, where uTorrent had difficulty connecting and uploading to certain peers[/edit]

It is not new to 1.9. 80% of connections to 1.8.1 are uTP. So it is in some form in 1.8.1 as well, which also explains the announcement about 1.8.1 peers. Rate Control and Latency minimization are nice, but, how do they work out if your router or software on your computer is doing the same? E.g. I can't turn on automatic bandwidth control in uTorrent because it gives impaired performance.

How long has uTP been in uTorrent? I'm seeing uTP connections to both uTorrent 1.8.1 and BitTorrent 6.1.1. Which means that the announcement is wrong.

Nice :-) I was wondering when the next alpha's/beta's would be comming. Confused. What is that supposed to be? UDP tracker capability, UDP hole punching or ...? Where is more info? Same here, more info please. Both can mean a lot of things. Sidenote; I didn't see any options in the Advanced Settings to control these functions.

@dockersfan: which firewall are you using?

Only thing I noticed so far was that after upgrading to RC1 the value for bt.no_connect_to_services was false, while I had set it to *true on the previous beta.

Doesn't leave much time to test :-)

Any specific reason why router.bittorrent.com is removed as DHT bootstrap?

That is because uTorrent can't handle SSL/TLS connections, so it is quite logical. AFAIK uTorrent won't get support for it in the near future, unfortunately (though understandable since it would be a lot of work to code it) :-( I really would like to see it though.

I don't see why that makes a difference. Whether or not the TCP-connections is an established one, or in another state, the port is still in an used state. Another point; how much accuracy is absolutely neccessary? And how expensive is that accuracy? Another problem with TCP is that you (tracker) are also dependend on how well people configured their TCP-stack, how good the TCP-stack actually is and how good the connection actually is (packet-loss, latency, etc). Looking at my own TCP-logs, I'm sometimes baffeled about what I see. Ridiculous MTU-sizes, ACK's that seemed to get lost leading to useless resends, extremely high latencies, etc. I can imagine that a tracker can have a pretty though time dealing with those.

I would say, yes, but I guess it depends on the network-equipment, OS and tracker-software as well. TCP-connections are slow compared to UDP, so at any given time, you would have more active connections (at least, without knowing the exact implementation, that is what I expect). But UDP comes with it's own issues of course. I personally support HTTPS-connectons :-p A serious flood/spike of either will probably crash/DoS both UDP and TCP trackers.

I think he would like UDP-support because it is (said to be) more efficient. If you have a large bt-tracker, all those tcp/http connections take their toll. Just thinking of the difference between UDP and TCP (no clue how UDP-tracker-support is implemented) I can image that a HTTP (TCP) tracker needs a lot more beef than a UDP one. Most trackers I know have issues with crashing and downtime. Not sure why, but I can imagine that it a flood of tracker-connections (when something hot gets posted or people switch on BT en mass) over HTTP/TCP will crash the tracker or lock up the box entirly.

Hm... that change is a few builds old, but I just thought about it right now, and was wondering... is DHT considered a tracker, and get limited in the same way? And if not, would it be a major issue (for DHT-performance) if the number of connections got limited, or would it just make DHT announces take a little more time to return results? DHT is UDP, so it doesn't have half-open connections (pure UDP is stateless) and there is no real need to limit it the same way as TCP (though some limit should apply for slow computers, pre-w2k systems and people with poor network hardware). I would guess that there is some other limit applied for UDP connections than for TCP connections.