Super Seeding

From AzureusWiki

Jump to: navigation, search

What is Super Seed mode? When should I enable it?

Super Seeding is a special optimised seeding mode.

Only use this mode when you are the first and only seeder.

Each peer will be assigned a piece, and Azureus will then compute the time it takes for that particular piece to be seen again the swarm, thus identifying peers with high upload speed, to which Azureus will preferentially give data.

When activated, additional information is available in the details view, right-click, "Choose the columns to display".


Some additional info from Filesoup

ADL_242:

Well, Azureus seems to do it differently:

It just goes from piece 1->N and if two peers are connected, then it alternates between both. And even if a peer that got a few pieces, leaves, Azureus doesn't go back (not even after reaching piece N) to replace the missing pieces - which is ok because the peer might come back. So never any random pieces in superseed mode.

The most sense I can make of this, is that what I call Azureus-~SuperSeed mode(the piece 1->N behaviour), is in fact some pre-~SuperSeeding mode, and Azureus goes into the ~BitTornado-type of superseeding after piece N.

But again, I don't really see any proof of this, because when the switch is made, all connections are renewed, and I haven't seen Azureus make a priority out of connecting to the people that had the most pieces. And when those highest-ranking peers reconnect, Azureus doesn't seem to favour them either. This may not be a bad thing, because it increases the sharing-time, but it does put a little bit more strain on the ~SuperSeed.

Gouss:

Azureus superseeding mode is for initial seeding only (or 1 seed only).

It goes through pieces from start to end.

It announces one piece at a time to peers and prioritizes big uploaders.

A piece is taken off the list of pieces to send if:

  1. it's been sent once,

    or

  2. it's already available in the swarm.

Once each piece has been sent once (or is available once), Azureus switches back to normal mode. (It has to disconnect because it announced different bitfields to each client...)

This superseeding mode is automatic, but you can choose to use it or not.

If the swarm needs superseeding, it'll kick in, and back out if not.

Restrictions:

Normal seeding mode doesn't include a "rarest first" on the server side.

As pointed out, if a peer quits, the pieces sent to him won't be sent again.


Q: When looking at the Details, the extra Super-Seed Mode columns (Piece & Time to resend Piece) show None and blank. I have Super Seed checked in the Configuration Seeding options, but does this mean that I'm not Super Seeding even though I'm the only seed in the swarm?

A: Correct, you are not Super Seeding. This is probably because you didn't restart Azureus after you enabled Super Seeding (and thus the change did not take effect).

Q: If Super-Seed mode uploads 1->N pieces to all the peers, why not use super-seeding for more than 1 seeder? If Azureus identifies the pieces in the peers and only send the pieces that are not on the peers, why not force super-seeding with 2 or more seeders?

A: ? (thanks)

Comment: BitComet interferes with Super Seeding?

It looks like BitComet doesn't play nice. BitComet clients disconnect and reconnect as soon as they have a piece downloaded from the Azureus superseed. Thus, Azureus never gets a chance to determine whether the client is a big uploader. To make matters worse, for some reason Azureus will upload to the "new" peers before uploading to known big uploaders. It appears to me this has a pretty bad effect on the effectiveness of superseeding.

I get much better performance if I regularly kick and ban all BitComets manually.

(In order to effectively ban unwanted clients I suggest using the Stuffer plugin available at: http://azcvsupdater.sourceforge.net/ )

Comment: Peer "cycling" bad impact on superseeding?

Older version of Azureus seemed to have different behavior when one limits the number of peers: they did not allow new peers to connect when the per torrent limit was reached.

The latest versions seem to rather opt for dropping/kicking the longest connected peers and allow newer peers to come in.

This appears to have a bad impact on superseeding. Several bad things happen:

  • bitcommets force out other peers (and see my previous comment why that is bad)
  • Sometimes known good uploaders get dropped for unknown uploaders who then get priority over all others.
  • If cycling is fast enough, only new entrants get the majority of the upload. Many of these are "bad" uploaders and bandwidth is wasted.
  • It appears that peers in the middle of DL-ing a piece may get dropped if they are the longest connected and new peers come in much bandwidth is wasted because the piece never gets fully uploaded and cannot be shared by the peer.

All in all, the superseeding mode on the latest version of Azureus seems to work a lot worse for me than it did before.

Note: I used to get very good results limiting the max number of peers/torrent to around 30 to keep out the "repeated connect / disconnect" peers like BitComet and make sure I only upload to peers that "stick around" and have been proven to be good uploaders. But none of this works anymore. It may be more effective in the latest Azurues not to use superseeding at all.


Back to Tips and Tricks

Read the Azureus FAQ

Personal tools