Switeck

OleaSTeR, have you disabled DHT (both kinds), Local Peer Discovery, UPnP, NAT-PMP, and Resolve IPs? All of those make extra connections, possibly using UDP.

"I can run the client using uTP but the thing is that the transfers with some peers will drop to 0 so I don't use it." I have that problem on ComCast, and attribute that mostly to older uTorrent versions' broken uTP implementation as well as having a tenuous connection to them. I've seen uTP "overcompensate" for lag and drop to near-0 speeds for no apparent reason.

mcaspi, uTP causing speed drops to 0 can be attributed to multiple causes...can you test some things to rule out other causes? (Like testing without a router, as some go into block-ip frenzy when they see the blizzard of UDP packets uTP makes.)

2mb is not descriptive enough. You need to know your stable UPLOAD bandwidth max, in kilobits/second or megabits/second.

scanner, part of the problem is your settings. Your overheads are probably from packet loss and retransmits, and since uTorrent "sees" that overhead...that means UDP packet loss from uTP peer/seed connections.

It's not so much magic as studying networking for many years and being involved with file sharing for a decade.

Did you have the box checked to allow additional upload slots if "slow"? Look especially at which peers are giving you the most of the torrent. Is uTorrent returning the favor to them? (It may not be able to if they're at 90+% and you're at <10%.) Your line might work ok (outside of peak evening hours) with 640 kbit/sec upload settings, so try that. If not, you can experiment with settings between 512 and 640 kbit/sec.

Each torrent is its own little pocket file sharing network. If there's few/bad peers+seeds on one, there may be little-to-nothing you can do to improve the speeds of that 1 torrent. So...the 3rd torrent you're having problems with, how many seeds and peers are you connected to? How many peers on it are you uploading to? While uploading to a peer, are you uploading at least 3 KB/sec to it? Forcing-starting a torrent means it ignores queue settings rules. This can play havoc with uTorrent's performance, as having too many active torrents at once often means connection/networking overload and considerably reduced speeds.

saintsoh, your ISP is partially to blame for your torrenting problems.

That's working as designed in v2.0.4 -- trackers on the same tier should only show the active tracker from that tier in the tracker window/tab.Torrents shouldn't be spamming updates to lots of trackers every time. I've used v2.0.3 as well and it handles tracker display the same way as v2.0.4 in tracker window/tab.

praneshs, Your ISP probably disrupts and throttles more than just uTorrent. But to get the most from uTorrent you have to disable some of its features that use bandwidth. 1st, 2nd, and 3rd links in my signature.

"And why enabling by default encryption will be bad ?" EVERY connection made using encryption has to do an encryption handshake -- which seems to take at least 0.5 KB...maybe up to 10 KB...even if the connection is instantly dropped and retried again 1 minute later. It adds up when people are trying to do 100's of connections at once. Outgoing encrypted for you is just fine, because uTorrent cannot disable incoming encryption directly. Only by blocking incoming entirely is a workaround of that! So those that need encryption can use it and those that don't aren't penalized by it, it is best to not have encryption by default for everyone. Another reason is because HOW some ISPs throttle/disrupt -- they may allow 5-100 KB/sec of unencrypted BitTorrent through and also only 5-100 KB/sec "unknown" traffic through and block the rest. Allowing only 1 or the other is not good for them, but if everyone's using encryption they are worse off.

Not everyone is throttled/disrupted by their ISP. Of those that are, many are not helped by encryption...at least not alone. So it's bad if it's enabled by default. Encryption can still be forced -- as far as I know uTorrent won't go without encryption to a peer/seed that is flagged for it via PEX.

Try methods mentioned in 3rd link of my signature. Some are contradictory and you'll possibly need to do only parts of them to see some relief.

Users *OFTEN* get angry with us being unable/unwilling to solve their problems despite not giving the requested information. If we don't get tough, they will even go so far as blame uTorrent for every possible failure they're having.

I have to know a working monospace font format and/or working tab stops to fix it.

"Cheaper then buying a switch to control bandwidth." Do you mean a managed switch, like something really expensive from Cisco? Because most 4,5,8 port switches have no bandwidth controls to speak of.

Possibly neither! Those speeds are likely your burst speeds only, not the sustained speeds. That service a EuroDOCSIS 3.0 cable ISP? Try 1mbit/sec upload settings first...increase it up to 3 mbit/sec (what the speed test said) only if it can sustain the upload speed at what you set it to for an hour straight. Do note that during peak evening hours it'll probably be (much?) slower.

It can also be the torrent/s you're running.

Download overheads can be caused by uploading or DHT.

If you have a LOT of torrents loaded, uTorrent has to check files to see that they still exist on startup. Takes even longer to contact all the trackers if they're all active.

I think it was mentioned on the v2.1 thread that uTorrent changed how it handled accessing files (starting with v2.0) so that it could do BitTorrent streaming. Windows stupidly ended up holding those files in cache when it shouldn't because of that...and memory use ballooned.

A seed's goal is to keep availability of the torrent parts high, but if peers refuse to download the rare pieces first a seed's entire upload speed can be "spent" uploading parts multiple other peers already have. This is especially common for first+last pieces of files due to BitComet demanding those first and uTorrent/BitTorrent can be set to demand those pieces with a much higher priority. So a seed that's set to stop at a fixed ratio may stop before every piece of the torrent is uploaded to the peers. I've also heard about seeds stopping in disgust after seeding 4-10:1 and not seeing any other seeds on the torrent. We get posts occasionally where people want to ban the peers that don't share, but refuse to add anything like that because many times the peers that don't share simply don't have any pieces that other peers don't already have. With firewalled and bad ISP peers/seeds mixed in, many peers and seeds cannot upload to all the peers on the torrent. Ideally, peers should download different pieces than each other, or the entire demand can fall on the (few?) seeds...and even BitTorrent's whole concept can fail.

If a torrent says in the tracker window/tab that "peer exchage not allowed", then it is a PRIVATE torrent that forces you to only get peer/seed ip lists from the tracker rather than via other peers/seeds using Peer exchange. Make sure the tracker/s isn't down, because if it is...you're probably screwed out of ever completing such torrents.

That much is correct, and that window is virtually identical to uTorrent's. So too probably is Queueing tab/window under that one in the list.