Is Super-seeding broken in µtorrent?

[Kluelos]

Flame not. I ask the question because I don't believe that it is broken -- and that it seems to be working as designed.

The trouble seems to be that most people including some torrent sites, think it was designed differently than it was, and does something differently than it does. I have certainly been told things about it that ain't so. So let's start with a couple of points:

- The guy who invented it, (John Hoffman for BitTornado), doesn't think it'll finish seeding a torrent faster.

- It wasn't ever intended to seed torrents faster, that's not why he invented it.

- It's really misnamed, and should maybe be called "frugal seeding"

Demonoid (not to pick on them, they're just one example) has it wrong in their FAQ. Or if not wrong, quite misleadingly expressed.

The point and purpose of super/frugal seeding is to encourage seeding by those who pay for bandwidth per upload KB, and it tries to make seeding for them as cheap as possible by assuring that they never upload an unnecessary piece. This is not quite the same thing as not uploading duplicate pieces, though it's subsumed in that idea. (The point being, if you're in that situation, it clearly discourages seeding by penalizing the activity financially.)

If you're a leecher and you get piece A from the frugal seeder, you'll start spreading it around while the seeder distributes other pieces. Eventually, your "turn" comes again and the frugal seeder considers giving you piece B. But before it will do that, it must have been in contact with at least one other peer offering it piece A. -- Proof that you've spread A around to the rest of the swarm.

If, for whatever reason, nobody it's connected to has offered piece A, then the frugal seeder won't give you piece B. You'll just take your place in the queue, and you won't get another piece from the frugal seeder until somebody other than you offers it piece A. The normal seeder would have just sent you piece B in turn and moved on.

Given a very efficient network, this process ought to work fairly smoothly, but in practice, eh, maybe not so much.

One thing you can hopefully see is that the uploading of every piece before repeating one lies somewhere between artifact and myth. If it DOES happen, it still wasn't the primary focus, the reason things were done the way they were done or precisely what Hoffman was aiming at. That was just (maybe) the result.

Another thing is that the constraint doesn't really seem to be there, or at least not in the theory or Hoffman's explanation of it. He doesn't explicitly say that there will be no duplicates. It somehow got assumed, and I suspect that it got assumed not just for consistency with his basic purpose of avoiding unnecessary uploads, but because that's what normal seeding might try to do anyway -- get all the pieces out there with as few duplicates as possible. It would be the most efficient way to do it. But I don't know that for sure, and I don't think we'll find out for sure without a peek at the code or word from on High about it. Anecdotal experience contradicts that, but we know what that's worth.

My own anecdote is, like others here, that my upload speed for a given torrent seems to be lower when I super-seed it and faster when I don't (given I'm the sole seed).

The last thing is that for the frugal seeder to know whether piece A has been spread, the seeder also has to act as a sort of leecher. It has to appear to be a leecher in order to get offers of pieces from the real leechers, which is how it knows that piece A finally made it to somebody else. (In normal seed mode, naturally no peer would offer a piece to a seeder.)

So if you're in frugal-seeder mode, you'll notice a very low-level DOWNLOAD activity on the torrent even though it's complete. Something like 0.3KB/s or less. (That's this not-quite negotiation going on.)

One thing I'm pretty sure of is that this will not be faster than normal seeding, all things in the real network considered. If all goes perfectly, it might be AS fast, but probably not consistently faster. That's not what it was designed to do. And that all that download bandwidth, small as it is, is still basically wasted. (Its target users aren't payiing per download KB, so it doesn't matter as much to them.)

It does seem to be working in µtorrent per spec. But the spec suggests that almost no-one should use it at any time -- only single seeds on a pay-per-upload-KB connection would ever get any definite benefit from it because their ISP bill would be minimized. Everyone else would be at best, no faster, and probably a little to a lot slower.

[Firon]

By broken we mean that you often need MORE bandwidth to get a full copy out than with normal seeding.

[DreadWingKnight]

The super-seed mode is intended to reduce the amount of transfer to generate full distribution.

uTorrent's current super-seed algorithm fails to provide that, sometimes requiring over 3 times the transfer of normal seeding to generate full distribution. A working algorithm would get full distribution in under 125% of the torrent's total size transferred.

[Kluelos]

Now let me editorialize on my own post. Bittorrent clients probably SHOULD be made to prohibit super-seeding if another seed is detected. The reason is that continuing to super-seed in the presence of other seeds is STILL to the benefit of those few who would benefit in the first place -- their bandwidth bills will still be lower. It would slow the REST of the swarm down, though.

So yes, I think the clients ought to prevent it when not the sole seed, because of that situation.

[DreadWingKnight]

Actually, the number of seeds do not have the same effect you believe they do.

Super-seeding, even in groups, is effective up to approximately 500kbyte/sec (from the seeds)

The reason the swarm gets slowed down is because of tards who don't upload, not because of the super-seeding algorithm itself.

[Switeck]

Another reason it might not be effective is the optimistic unchoke for new peers may be overriding super-seed's goals. ...and BitComet (at least in the past) was deliberately exploiting optimistic unchoke for new peers by disconnecting and reconnecting if they don't get an upload from you in a minute or so.