Jump to content

Why am I snubbing so many potential downloaders?


Recommended Posts

I am having a nightmare of a time with uTorrent as documented here: http://forum.utorrent.com/viewtopic.php?pid=465646#p465646. At least right now it would seem that my setup can sustain max upload rates. However, I am having no joy with my downloads (one of them being OpenOffice for testing purposes). Two questions on that:

(1) When I go into Options/Preferences/Connection and change my uTorrent port - and not changing anything else - all of a sudden I get a lot of downloading activity (from new peers) where previously there has been none. Why?

(2) Despite 25 peers queuing up to feed me AND my actual download rate being WAY BELOW potential (and my not running with bandwidth management), I see a lot of "d" flags in uTorrent's peer pane. That's me, if I understand correctly, telling them that I don't want their stuff. Why? As a result of my unwillingness to take packets from them, they gradually all break away. And never come back. Until I either change port or reset the router.

Any suggestions welcome. Thanks.

Link to comment
Share on other sites

Hm ... well, I am not using private trackers (and since the demise of TPB much of my back-catalogue is now tracker-less). Also, the article reads as though if this really were to affect me, it would manifest itself by my having no peers calling. Yet I have (now) plenty of people knocking, only that my uTorrent says "no, thank you." And that's the bit I don't get.

Link to comment
Share on other sites

JPGs are little tiring so forgive me when I simple type the few params you're after (trust me not to lie):


Max upload: 25k (though I limit to 20k during day time).

I am consistently max'ing out on this for the last 3hrs).

No alternate.

Global download: 100k (again, I limit this to 80k during day time).

As I type this, OpenOffice is blasting down with 80k and all peers are flagged "D". This was prompted by my once again changing ports. I'd normally stop OO when I see it downloading but I thought I let it run the course this time. Looks like it's going to get there.

Of course, I have a few copies of OO already so that's NOT the download I am most concerned with ;) The torrent that I am interested in gets up to 25k while I'm still acquiring peers and then gradually grinds to a halt over the next 30-odd minutes as more and more peers turn from "D" to "d" and eventually break away.

Global max connections: 60 (number of half-opens: 80, patched and no errors in sys event logs)

Max peers per torrent: 35

I should be so lucky. Ever since I run uTorrent 2.0, I am max'ing out on my bandwidth with way fewer peers compared to previous versions. Mind, 2.0 has not really settled down.

Number of upload slots: 4


All enabled EXCEPT "limit local peer bandwidth"

This really surprises me since I would have sworn that my last action here was to disable again "bandwidth management". I have been occasionally changing this setting.


Max number of active torrents: 6

Max number of active downloads: 2

Seed ratio: -1

Unlimited upload rate.

The queuing algorithm is modified via the Advanced settings. In previous versions of uTorrent I found that:

queue.slow_dl_threshold: 5000

queue.slow_ul_threshold: 1750

ratonalized the upload behaviour. I don't think that slow_dl_threshold was ever an issue. In fact, I should try to reset to default to see whether it impacts "D" v "d".

I might also be able to reset the ul_threshold. I had a big disagreement with the seeding policy of uTorrent until 2.0. Previous versions would actively seed very little, preferring to leave most of my catalogue in "queued seed" state. I always thought that this was a deeply flawed approach to the community and slow_ul_threshold was a way of modifying this behaviour. I notice though that in 2.0 "queued seed" no longer appears to feature and instead 2.0 is seeding my complete catalogue - even though all upload slots are pumping data > slow_ul_threshold.

Update #1:

I was way too sanguine when I wrote that my upload problems appear to be solved. WRONG. It just took a lot longer than before. My current uTorrent has, according to Outpost, 130 connections open and ... I am talking to just 2 peers on ONE torrent. Uploading is now falling below potential; downloading has LONG stopped.

The dying moments from uTorrent on the download were:

[2010-03-15 16:30:00] [µTorrent 2.0 (10.0)]: Got Request: 1739:2260992->16384

[2010-03-15 16:30:00] [µTorrent 2.0 (10.0)]: Got Request: 1739:2277376->16384

[2010-03-15 16:30:00] [µTorrent 2.0 (10.0)]: Got Request: 1739:2293760->16384

[2010-03-15 16:30:00] [µTorrent 2.0 (10.0)]: Sending Piece 1739:2260992->16384

[2010-03-15 16:30:01] [µTorrent 2.0 (10.0)]: Sending Piece 1739:2277376->16384

[2010-03-15 16:30:01] [µTorrent 2.0 (10.0)]: Got Request: 1739:2310144->16384

[2010-03-15 16:30:02] [µTorrent 2.0 (10.0)]: Sending Piece 1739:2293760->16384

[2010-03-15 16:30:04] [µTorrent 2.0 (10.0)]: Sending Piece 1739:2310144->16384

[2010-03-15 16:31:01] [µTorrent 2.0 (10.0)]: Send Choke

[2010-03-15 16:31:39] [µTorrent 2.0 (10.0)]: Disconnect: Connection closed

[2010-03-15 16:36:00] [µTorrent/ (0.0)]: Disconnect: Too many global conns

[2010-03-15 16:42:03] [µTorrent/ (0.0)]: Disconnect: Too many global conns

[2010-03-15 16:58:00] [µTorrent/ (0.0)]: Disconnect: Too many global conns

[2010-03-15 17:04:22] [uTP]: Disconnect: Peer error: An existing connection was forcibly closed by the remote host.

[2010-03-15 17:04:22] [µTorrent/ (0.0)]: Disconnect: Too many global conns

[2010-03-15 17:04:23] [uTP]: Disconnect: Peer error: An existing connection was forcibly closed by the remote host.

[2010-03-15 17:04:32] [uTP]: Disconnect: Peer error: An existing connection was forcibly closed by the remote host.

[2010-03-15 17:04:43] [uTP]: Disconnect: Peer error: An existing connection was forcibly closed by the remote host.

Come on Switek, Firon and DreadWingKnight. Feel free to call me an idiot but please provide some input as to where else I might look. Thank you.

Link to comment
Share on other sites

"I see a lot of "d" flags in uTorrent's peer pane. That's me, if I understand correctly, telling them that I don't want their stuff."

Actually, no..."d" means you want something they have (are interested) but they are not ready to upload to you at this time. Were they ready to upload to you, that should switch to "D" flag.

If you want to understand why, look to your own "u" and "U" flags. You have limited upload slots because uploading slowly to many is FAR worse than uploading quickly to a few. Peers can't share partial pieces, only whole and checked pieces. So if the piece size is 1 MB and someone is occasionally (roughly half the time) uploading to you at 0.5 KB/sec then just to complete 1 piece from that source alone would take over 1 hour.

The average seed or peer allows 50 connections per torrent but only has 1-4 upload slots. Even if they're connected to only 40 peers and using 4 upload slots, that means they only upload to a particular peer about 10% of the time.

Link to comment
Share on other sites

Ok, so I got it the wrong way 'round. So perhaps they give up coz I am too slow up to them. That's fine. I also don't have a problem with my peers falling in number down to 3 or 4 so long as availability stays around 1. But it doesn't stop there. I keep losing peers until there's no-one left. Just been out for a couple of hours and there's zero activity on uTorrent upon my return.

I am intrigued by a contradiction:

Outpost tells me that uTorrent has 140 connections open (I assume that that's 60 max conns + 80 half-opens). I have ZERO peers (down + up). Yet I have errors in my diagnostic log reading "Disconnect: Too many global conns". Doesn't this sound to you like uTorrent might not be closing connections properly?

Another observation: upon exiting uTorrent (when uTorrent goes into its graceful closing mode), Outpost initially reports a doubling of the connections before, one by one, those are all closed and uTorrent exits. Normal?

Link to comment
Share on other sites

"Yet I have errors in my diagnostic log reading "Disconnect: Too many global conns"."

You mean uTorrent's Logger window/tab?

set net.max_halfopen = 8


set bt.connect_speed to only 1-4. (Your choice there, higher won't matter really if you get the green light at bottom.)

Link to comment
Share on other sites

"You mean uTorrent's Logger window/tab?" Yes, I right-clicked in peers pane and selected "log traffic to logger tab".

set net.max_halfopen = 8

set bt.connect_speed = 3

I also last night reverted back to 1.8.5 again, just to see whether I could get back to my former life - no joy (*). Something has changed on my m/c that's exogenous to uTorrent but is impacting both 1.8.5 and 2.0. Unfortunately, the box has been through so many changes since I had to cull COMODO that it's hard to understand where these problems originate.

As I write this, I have re-started 2.0. It found ONE peer and that's all its was talking to. I then did the usual trick: choose a new port. And off it went again, finding a couple more peers. Question: What state/condition leads to a complete falling away of peers and can be resolved by changing the port? Put another way: Is it more likely that my uTorrent is electing not to talk to the world OR that the world is electing not to talk to me?

I thought initially that my router or ISP is at fault. But I'm no longer so sure. Could of course be that the router will only pass x bytes through a port before closing it. Far fetched but possible, I suppose. It is curious, for example, that I am not having much success with ports 40000, 50000, 40000. The second 40000 does not unblock very well. I have more success with 40000, 50000, 60000. That is, I need to assign "new" ports. (**)

Do peers maintain blacklists? Perhaps for IP:port combinations? What do I have to do to get on such a blacklist?

Can I ask once more: why is there no correlation between the number of connections seen by Outpost and the number of peers entertained by uTorrent? Put another way, what are all those open ports doing when nothing's going on? Outlook reports most connections as listening on [myPort].

Despite my aversion to JPGs, I thought I take a snapshot of my current session. Perhaps you can have a quick glance to see whether anything untowards catches your eye? snapr.jpg The downloading torrent (on top) is already in retreat: it has lost more than 5 peers already and it won't be long before the whole thing comes to a halt.

Thanks Switeck.

(*) One observation on last night's performance. uTorrent (1.8.5) settled down to exchange pieces with ONE peer only and both sessions led a merry dance: when my last piece was slow, he would slow down; when my last piece was fast, he would speed up. The correlation between my upload and download speed was near perfect, with only a slight time shift. Design? It does keep me in the game for the longest possible time but my download speed doesn't even begin to max out with this strategy.

(**) I can confirm though that even when uTorrent is in its autistic state, an external port checker still perceives [myPort] open.

Link to comment
Share on other sites

Use PNG for screenshots...less fuzzy and smaller filesize.

Did you try disabling UPnP, NAT-PMP, DHT (both kinds), Local Peer Discovery, Resolve IPs (right-click in Peers window)?

What's your current CTRL+G Speed Guide settings?

I don't know if you have any other strange settings in advanced...so tell me any non-default values there.

Link to comment
Share on other sites

Use PNG for screenshots...less fuzzy and smaller filesize.

Apols - I'm no good at screenshots. Despite fuzziness, it was readable, right? Anything struck you as odd?

Did you try disabling UPnP, NAT-PMP

Yes, I did this initially when my router's firewall was interfering. Installed manual port forward then. The manual port forward did not help this problem, though. My router does appear to respond to the UPnP instructions from uTorrent correctly and so I have re-enabled UPnP since it makes switching ports easier.

DHT (both kinds), Local Peer Discovery, Resolve IPs (right-click in Peers window)

No, I never disabled these. I thought that in the post-TPB world when we all have to learn to live w/o trackers that these goodies became essential? Judging by the flags in the peer pane it would seem that most of my peers now are sourced either via DHT or PEX.

I don't know if you have any other strange settings in advanced...so tell me any non-default values there.

Here goes (wouldn't it make life easier for you guys if uTorrent had a simple "export config to text" option?):

bt.connect_speed = 3

bt.scrape_stopped = true

bt.transp_disposition = 5 this is a weird one - you wouldn't believe the number of times I've gone in there to reset it to default (of 15). Doing it again now...

gui.default_del_action = 3 - I guees you don't care about my GUI preferences?

queue.slow_dl_threshold: 5000

queue.slow_ul_threshold: 1750

and that's all there is.

Sorry, can I repeat my previous questions once more:

Do peers maintain blacklists?

What are all those open ports doing when nothing's going on?


PS: I might have to modify a statement I made earlier when I wrote that I need to assign "new" ports to re-awaken uTorrent. I am no longer so sure that this is true. A sequence of 40000, 50000, 40000 does appear to work as well.

Update #1

Guys, check this out. Those flags look pretty sick, right?


Also consider that I am way below my upload capacity. So there I have 20 peers ready to take from me and I am shipping zippo. No wonder they all take a hike after a wee while...

Update #2

ALRIGHT !!!!! WE ROCK AGAIN !! Check out this picture (of rude health):


How did I get there? I disabled DHT (as Switeck suggested) after I read Ultima's comments here: http://forum.utorrent.com/viewtopic.php?pid=213804.

This all leaves me with two questions:

(1) I do love uploading to lots of peers even if that implies slower speeds. But I do follow Switeck's reasoning some of the way that the picture above is NOT efficient. I am bewildered what happened to the "Queued Seed" state - it does not seem to feature anymore. I have a feeling that this is related to my catalogue having lost most of its trackers. Am I warm? How then, in the tracker-less world, can I be a little bit more focused in my uploading? I don't think that the #upload slots will cut the mustard: as the picture shows, I am only talking to 1 or 2 peers per torrent anyway. Any suggestions?

(2) I thought that DHT was vital for my survival w/o TPB but it actually turns out that PEX is doing just fine. The real question is, though, why uTorrent allows itself to be killed in this fashion by DHT? Or, as I asked in the parallel thread, is there a way to configure the resource usage of DHT better?

OMG ... this has been the most painful journey of discovery in months. Awful.

Link to comment
Share on other sites

No, it is not Switeck. You posted just as I submitted an update. Please see before.

Update #1:

Now that my most fundamental peer discovery problem seems resolved, I would like to return this thread to its original subject. Take a look at my 1 download slot in here:


During the day time, I have 80k down potential. Yet what seems to be happening is that, for the most part, uTorrent tries to match my downspeed to my upspeed. This may just be an understandable strategy as regards my exchange with other peers, but it makes no sense when it comes to seeds. I have watched this thing have a seed sitting in "d" state until, eventually, the seed just went away. All the while my download was crawling along with 5k. Is there sthg that I should re-configure?

PS: I have found the answer to (1) above myself: I reduced queue.slow_ul_threshold to 750 and that has curtailed the active upload queue.

Update #2:

"Enable bandwidth management" may of course have something to do with it. I have switched this off on countless occasions. OK'ed out of Preferences and then went back in to confirm that it's been disabled, and it was. Then I come back to it a few hours later only to find uTorrent's re-enabled it. My preference is not taking, in other words. And the same is true of "bt.transp_disposition" which periodically, and incongruously, reverts to 5 (after I set it to 15).

Update #3:

The penny's finally dropped: bt.transp_disposition = 15 and bandwidth management = disabled are mutually exclusive!! Put another way, setting bt.transp_disposition = 15 is equivalent to enabling bandwidth mgmt. Get it. So I am running now with

bt.transp_disposition = 5

bandwidth management = disabled

to see how that goes. Will post again later.

Update #4:

Folks, I am SUPER HAPPY again with uTorrent. This was an unbelievably painful journey but we got there in the end. The reason I was not sustaining downspeed (and snubbing potential downloaders) turns out be my global connection limit, which was simply too low for the amount of peers that I am aiming to connect. Over the past 1hr or so, I have sustained 80kB down. Thank you all for your input.

To give sthg back to this forum, let me post my setup (perhaps it will help someone else):


BT - ADSL Option 3 (unlimited; not the worst of the bunch - does shape traffic some but not to the point where you cannot do anything)


Belkin Wireless N Router s/n F5D8633-4

Firewall DISABLED - was interfering even with manual port forward (in Virtual Servers) - I will research this some more now that uTorrent has settled down.

UPnP enabled - it seems to be compatible with uTorrent.


Agnitum Outpost with the following rules:

(1) Allow Outbound UDP (all ports)

(2) Allow Outbound TCP (all ports)

(3) Allow Inbound UDP to 1900, 5351-5353, 6771, [myPort]

(4) Allow Inbound TCP to [myPort]

(5) Block (and report) all UDP

(6) Block (and report) all TCP

(If COMODO works for you, it's the better firewall. The same rules will work in COMODO.)

Anti-Virus (for what it's worth):

AVAST 5.0!

minus p2p shield

minus network shield

minus behavior shield


Version 2.0 configured as follows:


Enable UPnP

Enable NAT-PMP

[Add Windows Firewall exception, if wanting.]


Max upload rate: 25kB - limited down to 18kB during day time (trying to be nice to my neighbours/ISP)

Global download rate: 100kB - limited down to 80kB during day time (as before)

Global maximum number of connections: 200

Max number of connected peers/torrent: 35

Number of upload slots: 4


DHT Network: disabled - the default "enabled" was responsible for all my grief - I think that uTorrent developers need to look into what's going on with this module. We may need separate configuration parameters to reign in its network resource usage.

DHT for new torrents: enabled - not sure why I do this since DHT doesn't seem to work.

Loacl peer discovery: enabled - this option should really be pointless on home networks since your network should not feature more than one active p2p client (or how else will you manage bandwidth usage, fairness, etc?).

Ask tracker for scrape: enabled - for sentimental reasons - not really much use in the post-TPB era... (but perhaps this also applies to PEX?) (*)

Peer Exchange: enabled - practically all my peers come via this route given that DHT doesn't work and trackers are all but dead.

Bandwidth Management: disabled (**)

Options/Preferences/Transfer Cap:

This is cute but I don't think at all workable. The Bandwidth settings above assure that when max'ing out on uploads CONTINUOUSLY for 1 month that on the 28th of the month BT will send you a threatening email. In other words, these settings leave approx 20GB of headroom before they send the police round your place. That's plenty for my downloading activity away from uTorrent - for now.


Max number of active torrents (u+d): 6

Max number of active downloads: 2 - haven't tested two downloads at the same time yet - might need to increase number of connections further.

Ratio: -1 - seed exclusively by seed/peer ratio (*)

Options/Preferences/Advanced (those deviating from default):

bt.scrape_stopped: true (*)

bt.transp_disposition: 5 - this results from disabling bandwidth management above (**)

queue.slow_ul_threshold: 750 - this seems to be a good value to achieve continuous uploading on 5 torrents.

(*) I prefer "breadth of shelf" (you will always find a seed somewhere but you may have to wait) over uTorrent's default setup for "depth of shelf" (you can only have what everyone else is having but you get that real fast). In fairness, the uTorrent crew assumes that you are on a laptop which you will take down the moment you got what you wanted (to download). If (like me) you are up 24/7, the default settings will see to it that most of your bandwidth is added to torrents that have 1000+ seeds anyway. You decide.

(**) On the asynchronous lines (which most of us are on), it is the ease with which we max out on the available bandwidth *up* that the ISPs struggle with the most, not at all our downloading. Yet bandwidth management only ever appears to impact (negatively) my down speed - which is rarely of concern at all.


I must assume that all my recent troubles are down to TPB shutting down its tracker. I assume that this tripped the majority of my torrents from finding peers via TPB to finding peers via DHT. DHT appears to have swamped my network configuration, effectively shutting down peer discovery. If I configured 300 connections, then perhaps DHT would work? Who knows... I will run with PEX for a while. Looks promising for now.

Link to comment
Share on other sites

Ops, in English please?

PEX is working fine. For many torrents, this was the only service left after I deleted their only tracker TPB. (Just learned from moogly that I should have added OBT everywhere, and did that.)

DHT was the killer, as documented here. And I am apparently not the first victim as Ultima's comments elsewhere seem to indicate. She seems to doubt whether DHT can at all work across ADSL - not that I'd understand the technical reasons behind that statement.

With DHT enabled, I was looking at 300 open connections (according to Outpost and despite my having only 100 + 80 configured) and ZERO peers. Once I disabled DHT, uTorrent rocked.

I would very much be interested in an explanation. I would also be very much interested in which direction the p2p community is headed: should I really bother with OBT or should I just accept that some lawyer somewhere will shut it down some time soon and I had better get used to a tracker-less world? But that's perhaps a discussion for another day...

Link to comment
Share on other sites

DHT was probably crashing your router and/or firewall.

Clearly, yes, that is what happened (time and again). But should not two actions follow on from that:

(1) uTorrent should not ship with DHT set to ENABLED by default (when it demonstrably has the power to wreck pretty standard residential setups).

(2) If, as I assume, DHT may be key (in the long run) to the survival of the bit torrent technology (in the presence of ever-so-busy lawyers), should not development time be dedicated to finding the root of this problem? I guess I will make a bug report on the other forum...

Lastly, in Options/Preferences/BitTorrent, should I enable (as I have) "Enable DHT for new torrents" or not bother, given that I have disabled "DHT network"?

Link to comment
Share on other sites


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

  • Create New...