Jump to content

Auto peer dropper doesn't seem to work


tgp1994

Recommended Posts

Hello again everyone. I hear that there is some sort of auto peer dropping functionality built into uTorrent. Doesn't seem to work for me. Half of my connected peers list are sitting there doing nothing. Anyway if I can figure out if it's actually working?

EDIT: I just read up about it in the help guide. So a developer make another option where it will work regardless of if the connection limit is reached?

Link to comment
Share on other sites

Well, like my edit, it would be nice if there was an option we could check where they would get dropped regardless of max connections. I think that would just free up bandwidth and such. Also, it would be nice if there would be another column in the downloads section showing total # of connections.

Link to comment
Share on other sites

Make extra room.

Extra room for what, exactly? Bandwidth isn't an issue with inactive peers because communication would only happen sporadically anyway. There's always the chance that the peer will become active in between peer.disconnect_inactive_interval and your (arbitrary) 30 minute mark. Tearing down a connection (only to have to re-establish it later) for no real reason other than feel-good house-cleaning doesn't really help anyone, and is itself a waste of resources.

Link to comment
Share on other sites

If a tracker suddenly comes online with tons of peers, then there will be space for them. And isn't disconnect_inactive_time in seconds, not minutes? Also, like I said, it could temporarily add them to a blacklist, say for half an hour or an hour, user specifiable I guess.

Link to comment
Share on other sites

Yeah, it is in seconds... but I didn't suggest it was interpreted in minutes either. X seconds to Y minutes is a perfectly valid interval/comparison.

If a tracker suddenly sends you a bunch of peers, it doesn't mean all of those peers will connect to you, or that they would be any more active than the peers you're currently connected to. You're banking on the chance that they will be, but the chance that they will be certainly isn't any higher than the chance your currently-connected-but-inactive peers would become active. You're assuming newly-connected peers will be active, but that assumption has no basis in fact, and as such, there is no reason to believe that such behavior as you've requested will work any better than the current behavior. Your suggestion is a tradeoff that comes with its own price, and to pay a price (or to trade disadvantages) for unknown gains doesn't really make much sense. Sure, it could be made optional, but that simply introduces additional complexity for (again) unproven gains.

If your connection limit hasn't been hit, µTorrent still will attempt to connect to new peers. It generally doesn't connect to all peers returned in the peers list anyway, so why would not connecting to a handful just because you have a few existing inactive peers (that may become active) make a difference? And if the new peers you get from the trackers do end up saturating your connection limit, µTorrent will start invoking peer.disconnect_inactive after peer.disconnect_inactive_interval elapses anyway.

In short, everything will take care of itself. You're trying to micromanage what doesn't need micromanaging for minimal gains (if any at all).

Link to comment
Share on other sites

More connections don't translate to more speed. There is little reason to feel like it must connect to as many peers as possible. As long as you set everything up according to the Speed Guide, things should be rather close to optimal. If you don't seem to be able to connect to more peers, then it's just luck-of-the-draw. It's a P2P protocol, so there are no guarantees as to who you connect to, and when/whether they will send you data. Some of the data sent by the tracker may be stale as well, and the peers may either no longer exist in the swarm, or may just happen to be offline when you attempt to connect to them.

Link to comment
Share on other sites

I think that's a fairly risky statement to make, saying more connections doesn't equal more speed. I'm surprised you didn't point this out yourself, but I'm sure one peer wouldn't dedicate ALL of their speed to me at one time, so the more peers there are, the more from each you get, right? Heck, that's what the Torrent protocol is all about.

Link to comment
Share on other sites

There's nothing "risky" about what I said. More connections don't translate to speed -- that isn't equivalent to saying that there is absolutely no correspondence between the two variables. The point is that there is a limit to how much more connections will improve speeds. Speeds don't increase linearly as connection counts increase, and the law of diminishing returns starts coming into play once you set the connection count disproportionately high (for your connection type).

You want to fill your connection limit with active connections -- fine. But that's not something you can influence, because again:

It's a P2P protocol, so there are no guarantees as to who you connect to, and when/whether they will send you data. Some of the data sent by the tracker may be stale as well, and the peers may either no longer exist in the swarm, or may just happen to be offline when you attempt to connect to them.
Link to comment
Share on other sites

Peers themselves don't know when another peer actually disconnects from the swarm. There is no mechanism through which peers can inform other peers that they're exiting the swarm (as opposed to simply disconnecting from each other -- which may not and often is not the same). To implement such a mechanism would be wasteful, as peers are entering and exiting swarms all the time, and if each peer were to tell every other peer that they're exiting the swarm, there would be millions (if not billions) of "goodbye" packets flying all over the place for no real good reason. Even if a hypothetical disconnect message were to be implemented, if we say peer A is exiting the swarm, and peer A knows of peers B-D, but not peer E (a very common happening), peer E may never know peer A exited the swarm because peer A would never be able to tell peer E.

Link to comment
Share on other sites

Yes, Comcast does throttle connections when their network is congested, using Sandvine. Encryption can't work around Sandvine, so there isn't much you can do about it.

On the other hand, this may just be a case of SpeedBoost coming into play temporarily. It may be that your connection doesn't normally upload at 250+ KiB/s except during SpeedBoost periods. In which case the graph may not be all that surprising. Your graph indicates that you aren't limiting your upload, which is bad. Select the proper upload rate in the Speed Guide, as has been alluded to several times before.

Link to comment
Share on other sites

I'm on ComCast and only have 1 megabit/sec sustainable upload speed...but get short speed boosts (up to about 1 minute) that may go as high as 350 KiloBYTES/second.

Long-term though, my upload speed max is only 120 KiloBYTES/second.

This is by design, as I have the 6 megabit/sec down 1 megabit/sec up plan.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...