Jump to content

Percentage d of total varies a lot, opt. to excl. d from conn. limit?

John Peterson

Recommended Posts


My last post was quickly thrown in the trash so I rethought regarding my basic problem and changed the post to this. In short my question is sometimes 10 of 50 connections are active (downloading or uploading), the rest are d, what about an option to exclude d from the connection limit or making a torrent specific connection limit?

Again, I searched the FAQ and the forum and tried to prevent that this is a double post, so please forgive me if it is.

For most torrents it seems like about half of the connections are downloading at any given time, and the other half is d. But for some problem torrents 20% or less is downloading and the other are d, and as a result the download speed is often on total very bad. If the percentage d of the total was about the same for all torrents I think that increasing the "maximum number of connected peers per torrent" would be an option enough to prevent this problem. But it's not about the same, it's very uneven from torrent to torrent, it may vary between 20% and 80% or more than that. I think an option to exclude d from the connection limit for all torrents may be helpful. Perhaps the option could be per-torrent if that would help.

I could mention that as an experiment I increased the total and per torrent connection limit to very high but utorrent would still not come near that limit, it would go at most to about 75 connections of the total 1 000. So if there is a tendency for trackers to limit one peer's total number of connections perhaps an option I to have d connections that have been inactive for a certain time to be closed and snubbed (until utorrent have tried all other peers in the swarm for example) would work better?

(Concurrent with this problem the torrents also seems to have a very high uploaded/downloaded ratios, a s high as 3 or 4. At first I wanted to have a peer specific ratio limit but now I realize that excluding d from the connection limit is probably what I'm looking for.)

What do you think? I'm using version 1.8.1. With d I mean the d flag that means "your client wants to download, but peer doesn't want to send (interested and choked)", basically some kind of standby status as I understand it where there is still technically an open TCP connection with the peer but no data is being exchanged.



Link to comment
Share on other sites

I only run one... just looking for a better way to optimize my bandwidth by making sure I stay connected to more active peers. However I also notice... usually when they go past 5 min it doesn't remove them right away I've seen many approach closer to 6 min...

Also even though I have a 768up/7Mbit down connection I have a poor router that doesn't like lots of connections. So I have to set lower connection limit to get decent speed out of my torrents, but the inactive peers really hurt my dl bandwidth. (The lower connection limits is why I only run 1 torrent at a time.)

Currently it takes about 20min... or 4 disconnect cycles for my torrents speed to "MAX" out.

I think there are so many idle peer with torrent because of too many people setting their connection limits beyond their connection/hardware's capabilities. For ex: If I set my connection limit higher it Max's out sooner, but over the length of the torrent the avg speed is lower to to the overhead of too many connections clogging my router's capabilities. (or at least that's my theory.)

Link to comment
Share on other sites

5 minutes is the minimum amount of time allotted in the bittorrent protocol. As purveyors of the protocol, it would be bad-form for their client to not respect this :/ Something to do with allowing for extremely low-bandwidth connections while still keeping active peers from churning too often. You must understand this means to disconnect the peer must not have sent ANY 16 KiB blocks of data in that timeframe. I would also suggest if you really see alot of peers not interested, you might be running "bad settings" which means you would get the same speeds with better efficiency with fewer connections-per-torrent/global and less active churn of connected peers.

Link to comment
Share on other sites

If you reach the connection limit, inactive peers will be dropped after 5 minutes of inactivity. So those d peers will get dropped, if there's other peers available.

Okay. I noticed the Inactive column now, and I noticed that the inactive connections are dropped after 5 minutes. However it doesn't seem like the number of connections have to reach the limit for this to happen. I had 1000 total and 200 per torrent as limit, but as earlier I only have arund 70 connections at most in the same torrent I used earlier, that now have around 1 300 peers. It must be that the tracker is limiting the number of open connections I can have?

Essentially, 5 minutes gives enough time for the choking algorithm to work efficiently.

What is the choking algorithm? Is it in the client or in the tracker?

Anyway, as I understand this now I need to have the torrent open for perhaps 15 minutes or 30 minutes or so before I have gotten either more slow peers to download from or have gotten lucky and connected to a fast peer.

And getting lucky with a fast peers seems most important because it seems like I can't download from very many more peers than I can upload to, because almost all inactive torrents are both d and u, perhaps meaning that they refuse to send because I refused to send to them? And if that is how it works, perhaps increasing the number of upload slots per torrent can help me download from more peers?

Update: It seems like the last thing worked. If I increased the number of upload slots I quickly got more peers to both upload to and download from. However, this will make the maximum speed I can upload with lower. But that doesn't hurt me because there is no peer specific ratio limit or other downside to seeding slowly right? So if I set the upload slots per torrent to basically unlimited (perhaps 1000 or so) my download speed will most likely gain from that right? (If I combine it with an appropriate upload rate limit of course so that the download speed is not choked.)

This leads me to suggest another option for the Bandwidth page. An alternative number of maximum upload slots per torrent when the torrent is only seeding. In my case lower, perhaps 4 or so. It may be a little selfish but it could work, because otherwise I would be tempted to close the seeding torrents to avoid hundreds of additional upload slots being opened.

Link to comment
Share on other sites

http://dessent.net/btfaq/#what CHOKE is what you do to all uninteresting clients. This happens to all peers you are not actively uploading to. It's part of the protocol.

If you're not connecting to peers you have an ISP problem, which likely wouldn't be solved by changing the protocol or telling others you can upload to them when you can't. When you don't upload to peers (who require upload) they repeat to you. Increasing upload slots shouldn't make that much of a difference in your speed. 1000 slots is stupid. How many connections are you making? If there are no more peers to cycle you don't disconnect, however there's no reason for any swarm to not give you download speed at least every 5 minute cycle UNLESS YOU have bad settings.

Here's a thought. Since you... seem to be unversed in settings, have you seen the "<90% upload" setting below your upload limit? This setting allows uTorrent to make more upload slots available BASED UPON GLOBAL LIMIT. Try it, check out alternate ISP choices in your area and read http://wiki.theory.org/BitTorrentSpecification to get more insight on exactly what goes on behind the scenes... All that non-data traffic your client makes is important to keep the swarm running.

Link to comment
Share on other sites


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

  • Create New...