Archived

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

Switeck

Seeding Torrent Max connections limit

Recommended Posts

A seeding torrent can only upload to so many peers before peers time out due to inactivity. Also, seeds have no need to connect to other seeds...reducing the number of connections a seed can get. A downloading torrent can sustain many more connections because only inactive seeds/peers that are not uploading or download get disconnected.

Beyond this max, peers go through a disconnect/reconnect cycle of repeated handshakes and increasing bandwidth used. Traffic shaping equipment monitoring traffic patterns is also more likely to interfere with these connections. EVERYONE LOSES!

While seeding, 1 upload slot uses optimistic unchoke -- which changes peers no quicker than once every 30 seconds unless peers disconnect. The other upload slots upload to the first peers that come along and change peers less often. peer.disconnect_inactive_interval = 300 seconds (5 minutes) by default. So any peers the seed has not uploaded to in 300 seconds gets automatically disconnected.

At 1 upload slot max and changing peers once every 30 seconds, this works out to be:

300 seconds / 30 seconds per peer * 1 upload slot = 10 max peers

This is the theoretical max usable peers for a seeding torrent limited to 1 upload slot, which is surprisingly low.

Each additional upload slot needs progressively less additional max peers, because they are increasingly likely to upload to the same peer for many minutes on end:

For 5 upload slots max: 300 seconds / 60 seconds per peer * 5 upload slots = 25 max peers

For 10 upload slots max: 300 seconds / 100 seconds per peer * 10 upload slots = 30 max peers

For 20 upload slots max: 300 seconds / 150 seconds per peer * 20 upload slots = 40 max peers

But as low as those maxes are, max peers for BEST results are lower still:

For 1 upload slot, 5 total peers connected leaves ample redundancy if a peer disconnects or a peer downloads too slowly.

For 5 upload slots, 10 total peers are plenty -- covering both disconnects and slow peers.

For 10 upload slots, 20 total peers with low odds that any 10 peers being too slow.

For 20 upload slots, no more than 30 total peers are needed because it is very unlikely 10+ peers disconnect AND remaining peers download too slow.

Lower max connections GREATLY increases the effectiveness of initial seeding!

Once a not-firewalled seeding torrent reaches connections equal to its upload slots, it has little need to make more outgoing connections. This leaves unused connections for incoming peers.

Share this post


Link to post
Share on other sites

So you're saying that people's settings in the default configuration are generally geared for the downloader, not uploader; that they're inefficient in large numbers; and are generally too high?

I usually sit @ 5x as many upload slots as connected peers for part of your reason, the other being I have like NO bandwidth.

Share this post


Link to post
Share on other sites

Yes, people's settings and even Speed Guide's settings are in general too high.

Downloading and seeding torrents are different enough to merit uTorrent having different max per-torrent connnection limits.

Single-digit (3-9) max connections per seeding torrent could work quite well...while that's almost silly for downloading torrents.

It would also let me redo my recommended Speed Guide settings to use even fewer connections. :)

Share this post


Link to post
Share on other sites

Switeck - I think this is a very good approach. Bittorrent has killed the usability of many consumer routers and has received negative reputation from ISPs. Configuring the default network resources to be minimal while maintaining similar transfer speeds would be awesome.

Share this post


Link to post
Share on other sites

The addition of uTP and Teredo/IPv6 connections only makes matters worse for weak networking.

bt.connect_speed defaults to attempting 20 new outgoing connections PER SECOND.

And unlike regular TCP peer/seed connections, uTP and Teredo/IPv6 are both UDP streams which are not bound to the net.max_halfopen limit of 8 connection attempts at a time.

This is why I recommend lowering bt.connect_speed to only 1-4. net.max_halfopen will still be the limiting factor.

Resolve IPs likewise in the PEERS window is more window-dressing than any real use. The country flags are often wrong, the reverse DNS values can be faked, and each one requires making another connection. (UDP typically, but possibly TCP) This too burdens already-strained networking...and does not help download/upload speeds in any way.

Local Peer Discovery seems like a great way to find fast peers/seeds, except it usually dead-ends its search at the first (unforwarded/firewalled?) router it hits. I've heard it uses multicast, which most ISPs block. So might as well disable it too. :(

DHT can be useful...unless you're only downloading private torrents or public torrents with 100+ seeds/peers. In the case where you're downloading a public torrent with very few peers/seeds, DHT may find additional sources...but sometimes doesn't...possibly because there's none out there. Disabling it can save about 0.5-8 KB/sec down/up. DHT uses lots of UDP packets and is notorious for crashing weak routers and USB wireless networking cards.

Peer Exchange makes up for DHT being disabled...if any of the peers/seeds you're connecting to has both DHT and peer exchange enabled, they'll pass seed/peer ip lists on to you. Let them do the work of finding them using DHT! Peer Exchange reuses existing peer/seed connections, and its bandwidth cost is often minor (only 1 message per peer/seed every 5 minutes or so.) It's disabled automatically on private torrents.

UPnP and NAT-PMP are automatic ways of port forwarding a router or allowing access through compatible software firewalls. If you did that manually, they're a (very) slight bandwidth waste...and possibly even a security risk!

Share this post


Link to post
Share on other sites

Seeing how the configuration for leeching and seeding are optimized with different settings, is there a benefit to changing how µTorrent behaves once the files you want are completed? For example, you may have 50 max peers per torrent, but that would perhaps change to 10 once you start seeding. Or perhaps have µTorrent be more aggressive about peer disconnects and only allow peers you upload to while seeding.

Share this post


Link to post
Share on other sites

Yes, it's a good idea to reduce connections per torrent down to 10 (or even fewer!) once all your torrents are downloaded. You might even want to use such low settings during peak evening hours if your ISP throttles or gets overloaded then.

Share this post


Link to post
Share on other sites

I see two different ways to tackle this:

1) Give us the option in the GUI to set max peer per torrent.

2) Based on the global max and active torrents, calculate a max peer per torrent from those numbers. Some sort of dynamic calculation to efficiently handle 128 Kbps uploads and 1 Gigabit uploads at the same time.

Share this post


Link to post
Share on other sites

uTorrent already dynamically limits max upload slots based on both max and current upload speed.

At ~1 megabit/sec (120 KB/sec), it allows about 25 upload slots if running a single torrent or only 1 upload slot per torrent if running 20+ torrents at once. This works out to be almost 5 KB/sec per upload slot. While running 4 torrents, it allows 9 upload slots each.

At lower upload speeds, upload speed PER upload slot decreases to below 2 KB/sec.

At much higher upload speeds, upload speed PER upload slot increases to 10+ KB/sec.

Even if the user sets upload slots per torrent higher than this, uTorrent will not use them.

A problem occurs if you have multiple torrents, some with 5+ peers and others with only 1 peer.

uTorrent still treats EACH torrent as having its max allowed upload slots and won't allow 1 to use the "extra" upload slots that aren't used by the others.

Share this post


Link to post
Share on other sites

as a remark,

So you're saying that people's settings in the default configuration are generally geared for the downloader, not uploader; that they're inefficient in large numbers;

if understood correctly,

this is

the main problem of the bittorrent protocol&it's users,

the lack of awareness to it's way of function.

please excuse the intrusion..:)

Share this post


Link to post
Share on other sites