Switeck

Under Preferences, BitTorrent... Limit Local Peer Bandwidth. You've currently got uTorrent to upload beyond max upload limit to any peer it considers "local". You might want to disable Local Peer Discovery (LPD) too.

Have you been through the troubleshooting guide? (1st link in my signature) It sounds like you might have something set wrong in uTorrent or conflicting software on your computer.

This isn't the place to ask for feature requests...and Relevance pretty much already does what you're asking...you just need to know how to read it.

Essentially, it's a minimum connections per torrent handler.

Actually hard to say. Slow public torrents with 1 seed and lots of junky peers...might as well run a few of those. But no matter how much upload you give out, they'll only give so much back each. Private torrents or seeding...you don't need very many to max out probably upload and download.

Beautiful pictures explaining my chart. Actually, max active and max downloading torrents are the most I'd recommend just about period. Optimum results are often achieved on the faster lines by running fewer torrents at once but with equal or slightly more per-torrent upload slots. (Keep TOTAL upload slots about the same or less as before!) Note: Seeding torrents can often run with slightly fewer upload slots and far fewer connections than downloading and still achieve the same upload rate. Unfortunately, uTorrent doesn't let you use different settings for downloading and seeding torrents. Total upload slots makes more sense than upload slots per torrent.

nightshifted, You may need to uninstall Sygate Personal Firewall at least to rule it out as a cause of your problems. (Reinstall it as needed/wanted after done.) I'm running Win 98SE on a computer here, and uTorrent v1.8.1 beta build 12285 runs here.

alus mentioned to me that port 0 is now used for "unknown" port ip sources...previously uTorrent was using port 65535. This is why I saw a bunch of port 0 ips in Peer Exchange in my last series of tests. Not a bug...but a "gotcha!" for those who weren't expecting it.

No, a port 0 ip doesn't (alone!) seem to cause it. I cannot reproduce a ghost half open on demand.

It seems I am still getting 1 'ghost' half open connection. Sorry I have no log of it happening. Started logging though... All I have is a Peer List...but if I had to guess, I'd wager this ip isn't "good" on account of its port address: 83.63.175.128:0 I'm seeing if I can't induce more ghost half open connections now. Seems not on my various tries...I guess that's good. I stopped the torrent that had the 1 ghost half open connection and restarted it. This seems to clear the ghost half open connection instantly. My half open limit has been set at 0 most of the time. I then raised half open to 8, then 20, then 30...waited for half open used to fall below 30...then set half open max back to 0. The ghost half open did not reappear. Whatever is still causing it...is bloody rare. Did the same thing again...no ghost. Saw this though: [2008-09-18 12:21:52] 83.63.175.128:0: Connecting: source: TI [2008-09-18 12:21:52] 83.63.175.128:0: Disconnect: Peer error: Error 10049 Log continuing to run...

slipkid asked: "Is that right?" Yes, everything above that question seems correct. The connection type is also based on measured upload speed limits. If you're getting way less than the ISP-stated amount, it's NOT a good idea to try to use settings based on the higher rate that you do not really have. The tested upload speed in KiloBYTES/second you get from a speed test...already factors in much of the 80% of actual connection speed. That's the TCP transfer max rather than the raw bits transfer max. However that is best used only for alternate upload rate while not downloading (only seeding)...as it's a little too high to use for regular upload max because it'll probably lag your internet connection a bit if downloading quickly at the same time. So take the measured upload speed and use the next lower value on my chart. rowben86, DISABLE: UPnP, NAT-PMP, LPD, DHT (both kinds!), and Resolve IPs (right-click in PEERS window on an active torrent). Each one costs extra bandwidth (though UPnP only from the computer to router or modem). That should also eliminate UDP packets from uTorrent. (possible exception: If you have Teredo installed, it uses UDP packets.) You only need to port forward TCP this way. Lower net.max_halfopen to only 4. (Constantly making 4 new connections outgoing at once should be enough!) Choose FORCED encryption outgoing, and disable legacy (unencrypted) connections incoming. (You can try allowing incoming legacy connections...but that's likely not to help.) Make sure you put in the correct UPLOAD settings for your connection! Not uploading at max speed at least some of the time suggests even worse problems than slow download! On top of all this, intentionally firewalling uTorrent and running with no more than 5-20 connections with half open set at 1-4 may be faster. Or removing tracker info from the public torrents so your ISP doesn't spot your tracker updates -- but this requires either DHT and/or Peer Exchange and doing a tracker update before removing the list.

I'm seeing the occasional tracker stuck in "updating" mode again, even when half open connections are set to 1-8. The trackers aren't timing out as best I can tell either. I don't know if the trackers are even being contacted. "[<ERROR>]:62001" in peer lists are unresolved IPv6 addresses. I get them all the time. It's a new feature that only first appeared in uTorrent v1.8 -- that they don't resolve suggests you don't have IPv6 support on your computer.

uthappyuser said: "It doesn't make a difference in the end with how fast they can get their work done, but it's nice to be able to start up quicker." uTorrent running with 150 half open connections at once is very high. Were it just making lightweight TCP connections with no additional overheads, it would still be high. But the BitTorrent handshaking process coupled also possibly with encryption detection+use...means that's a lot less upload and download that could've been sent actually downloading and uploading torrents. People see less than stellar download speed AND/OR "web lag"...so they reduce upload speed often without thinking about the causes or effects. If you're not firewalled and on a public torrent and especially if you have peer exchange and/or DHT enabled...then even 8 half open connection limit in uTorrent is more than enough. If you REALLY want connecting faster at start, set half open higher for a minute when uTorrent first starts a torrent...then lower it. Best of both worlds.

I recommend 8 half open connections (the default) for most cases. It is when people ALREADY have problems that I suggest lower. ("problems" = very low speed, lag, or worse.) Hopefully, a very soon v1.8.1 beta will be able to handle 8 half open connections just fine.

If it only takes 10-15 seconds to roughly reach your global connection max in uTorrent, then you probably set half open max WAY TOO HIGH! Reducing your current half open max value to half should make uTorrent take twice as long as currently to reach global connection max. So that'd be 20-30 seconds. How much downloading and upload could potentially be "lost" in the extra 10-15 seconds...versus the amount of bandwidth used attempting all those half open connections? My bet, you're LOSING speed.

At best right now, I'd see an advantage in trying possibly-local peers first...simply because almost regardless of the torrent swarm size, it is extremely unlikely that there's enough local peers to hit typical global or per-torrent max connections using them alone. And that is even using my reduced limits for lower-end connections. Too many are likely long-dead, firewalled/unconnectible, have nothing you need, or just plain running with terrible settings. (1 KB/sec upload anyone?) A few ISPs have an unstated policy of throttling BitTorrent uploads to ips not on the same ISP. You'd likely not even notice so long as a couple same-ISP ips were present on a torrent swarm. But having said all this, I don't see it worthwhile to go to any great trouble to find local peers or same ISP peers (which often aren't really "local" topology-wise) because quite frankly ISPs have been very unhelpful in that task. Most are unwilling to release ip ranges, and they're completely hostile to revealing any topology information.

Throughout this thread, I've already answered your questions a couple times over. Example of how to use the chart: http://forum.utorrent.com/viewtopic.php?pid=337049#p337049 Or if you already know your max sustainable upload speed, you could try settings equal or lower than that.

"I Dl Version 1.8 And All Dl's Went No Faster Then 12kb/s"... "I Checked The Bandwidths And They Were All Set Correct. Do a run-down of the 2nd link in my signature. You'd probably get considerably more than 12 KiloBYTES/second download speeds using the correct sustainable upload settings for your line.

Ah, that might explain this: Name Status Update In Seeds Peers Downloaded http://open.tracker.thepiratebay.org/announce offline (timed out) http://open.tracker.thepiratebay.org/announce.php Error 10061 http://tracker.thepiratebay.org/announce Error 10061 As apparently this affects one of my torrents too. Fortunately it had other trackers.

Just because the developers aren't posting here often doesn't mean they aren't checking uTorrent as you requested. But possibly they didn't find an easy fix or couldn't localize the problem. Can you do a wireshark log of just tracker traffic to the problematic trackers?

It takes bandwidth, even download speed, to maintain TCP connections to your computer. While uploading, there is also reply packets from the peers you're uploading to...which count as download by uTorrent. Handshakes when a peer or seed is first connecting is an additional download amount. By limiting per-torrent and global connections to a lower amount and/or reducing half open connection limit in uTorrent, the download amount used per hour while just seeding should decrease noticeably. Even allowing only encrypted connections might reduce the download amount slightly.

slipstream said: "While this behaviour (empty field = "do not change") is helpful when you set properties for several torrents at once." A bug is a feature once it becomes documented. Until I see that documented, it's still a bug.

I thought Windows 95d had a slightly updated winsock (beyond what Win 98b had)...and also USB support.

If uTorrent doesn't work with Win 95 anymore, you probably could still update Win 95's winsock or something and get it to work.

http://www.utorrent.com/beginners-guide.php