Balancing upload speed per peer?

[christiebun]

It'd be nice to be able to balance out the upload speeds for the peers on a torrent, so that one peer doesn't hog it all and the rest are, say, 1-2KB/s vs. 15-20kb/s for the one peer. Another thing that'd be nice is to be able to limit upload speed to be equal or less then download speed-- its not uncommon to see a peer sending <5ks and getting 15-20kb/s from me, and its very annoying, nor is it fair to the other peers I'm linked to on that torrent.

[Ultima]

Limiting upload speeds to download speeds only slows the swarm down in general. As for balancing... I do think µTorrent already tries, but if the other peers don't download faster, then they just get a smaller portion of the upload speed.

[olmari]

Also we have to keep in mind that at least in europe ADSL and cable connections are only too popular / only feasable connection method, and that also means that upload is so much slower than download. Like me, I have 24mbps downstream but freaking lousy 1mbps upstream and I can't do anything about that.

[Switeck]

Here in the USA, I'm on Comcast cable with 6 mbps down and 0.375 mbps up. Even in the USA, many have worse. ..and at higher monthly costs! (My total tv+internet cable bill is under $60/month.)

Upload speeds should NOT be limited to download speed simply because you cannot assume a peer isn't sharing with someone else. Nor can you assume that peer will leave once it gets the whole download. Even hit-and-run downloaders often fail to stop the torrent within 10 minutes of reaching 100%. BitTorrent's speed comes from these facts. Not everyone can be or should be equally rewarded for their efforts. There are too many real-world limitations and problems to compound the reward balancing to even seriously consider it. A best-effort tit-for-tat at the peer level is all you can hope for.

This feature request works against that goal, so I am against it.

[emtec666]

Upload speeds should NOT be limited to download speed simply because you cannot assume a peer isn't sharing with someone else.

Well you can actually assume a peer isn't sharing with the swarm if he takes x Kb/s from you and moves at almost the same x Kb/s. This can easily be determined by checking a clients' peer list now and then and observing the behaviour of the peers receiving data (I'm talking about uploading as the initial seeder here). I usually add these leechers to ipfilter.dat and (Lord behold) after that general swarm speed usually increases.

So I'm in favour of a x Kb/s per slot option. Due to low ping and/or outgoing encrypted connections (which can't be turned off on my side, meaning incoming encrypted connections) some peers can take up a large amount of one's bandwidth, decreasing the efficiency of piece spreading among the swarm.

[Switeck]

Which is to say you may know what it's doing on that swarm but not any other. And peer's reported (to trackers and other peers/seeds) download speeds are often erroneous. While it may be possible to calculate how fast a peer is downloading over long time intervals with smaller torrents, (by watching its % complete change -- though numerous clients misreport that too) if you're dealing with 1+ GB torrents then even downloading slowly from other peers+seeds may be hidden in the noise at least for awhile. With initial seeding, if a single peer is downloading quickly from you but over time you don't see it sharing with others (via faster % increases than you're giving them) ...then its not a matter of you balancing upload speed per peer -- it's a peer best manually banned IMO. Maybe worth removing the ban after a couple days/week, as their ip is likely to change or their sharing habits may.

However, the reverse in initial seeding -- if you see a peer who is only getting a % increase exactly equal to the amount you're uploading to it...while everyone else seems to be increasing at a faster rate (than just due to your uploading alone), then it's possible that peer is sharing just fine to others...it's just not being rewarded for its efforts by others. I've seen posts here from just such peers wondering why they're getting jack back while running µTorrent. Banning them is like killing a seed. It's one of the reasons automatic banning and a quick right-click "ban" button hasn't been added.

You seem to imply you're on an ISP which neccessitates you using forced encryption. Others are also on crippling ISPs but blissfully unaware of that fact, which may still allow them to download quickly but just not upload fast at all. Or vice versa in rare cases. Neither one can be load balanced.

Even an overall upload speed max is hard to maintain with varying conditions. I know, I've seen mine slide occassionally due to uploading to erratic peers. This would be trying to enforce a set upload speed to each peer. The inevitable consequence is often peers will fail to achieve even this set max...leading to your max upload speed not being maintained.

...or some degree of oversubscribe will be neccessary, meaning the upload speed per peer minimum will be potentally a lot less than "x Kb/s".

[emtec666]

You seem to imply you're on an ISP which neccessitates you using forced encryption. Others are also on crippling ISPs but blissfully unaware of that fact, which may still allow them to download quickly but just not upload fast at all. Or vice versa in rare cases. Neither one can be load balanced.

I don't use forced encryption, but my ISP does throttle BT traffic at the busy hours (meaning (incoming) encrypted connections tend to suck up most of my bandwidth then). That's my main problem. I'm not concerned with other ppl's connections, as an initial seeder all I want is to get more copies in the swarm as fast as possible. And I feel limiting UL speeds per slot can help to establish a more reliable transfer (meaning I don't have to babysit an upload but spread out the risk of encountering leechers over multiple slots).

Anyway I haven't heard any good arguments against limited UL speed per slot (especially in initial seeder mode), so please enlighten me

[DreadWingKnight]

Not all peers have the available download speed to max out the per-slot limits.

This will tie up slots with half-used and even quarter-used limits, which leads to slower upload slot rotation.

[Switeck]

Back when BearShare was trying to do dynamic upload slots, the head designer had the crazy notion that if someone didn't enter any upload speed max that he could "calculate" their max upload speed by slowly opening upload slots 1 at a time and letting them run at 3 KB/sec max each. Once an additional upload slot didn't run at 3 KB/sec each it was assumed to be running at max. This was a complete disaster on 2 counts. Firstly, this meant 3 KB/sec upload was the absolute fastest ANY upload slot would run. Secondly, if a very slow downloader came along then no more upload slots were opened and a LOT of upload bandwidth went to waste. It took us beta-testers a couple weeks and a few screenshots even on my lazy part to get dynamic upload slots changed into something useful. This was why the later dynamic slots could be configured for a minimum and a maximum amount...the minimum was to keep 1 person from hogging and the maximum was to keep it from spreading too thin.

I've also heard of Shareaza trying the same thing, with equally disasterous results. Seldom ever did I get a decent download speed from a Shareaza source, due largely to that alone.

Oh, I almost forgot...I used to use BitTornado. I was often running 1-10 torrents at a time. (If >5, then you can bet the torrents were either really small or nearly dead.) The minimum allowable upload speed was 3 KB/sec and the minimum allowable upload slots was 2 -- PER torrent. It was a nightmare to try to manage my upload bandwidth. I often ended up either wasting some upload bandwidth or overloading my upload bandwidth.

I was seeking a better BitTorrent program after that and fortunately found µTorrent after hearing about a few others. Had I not found it, I'd probably be on BitComet and complaining about its poor upload slot performance on its forums. I see it regularly being a bad BT uploader to me...often, I'm connected to one that uploads to me at 0.2 KB/sec or slower.

So I know how disasterously bad enforcing speed maxes on individual upload slots from firsthand experiences in very similar fields.

[emtec666]

Not all peers have the available download speed to max out the per-slot limits.

This will tie up slots with half-used and even quarter-used limits, which leads to slower upload slot rotation.

Though this might be true for small swarms, but not for medium/big swarms, there's always enough peers to max out potential upload slots, especially for initial seeders who don't have a great upload speed (let's say 2 Mbit and below).

Of course there's always super-seeding but unfortunately that doesn't work too efficient for medium/high upload speed (if I set my upload 1 Mbit then sometimes the speed drops to 30 Kb/s average when super seeding). Maybe there's still things that can be improved in the super-seed mechanism. That would be a lot better than a per slot UL limit.

[Switeck]

Yes, the super-seeding/initial seeding problems of VASTLY under-utilizing upload bandwidth qualifies as just plain bad IMO. Even with the understanding that it's not made to max out your upload speed, it still should make an honest effort to seed at a reasonable rate. But the way it is currently, 1 "leechy" peer or very slow downloading peer can hamstring it terribly badly.