Jump to content

Super seed works, but not properly


MP-A

Recommended Posts

I wish i had taken a screenshot when it happened, but heres the problem: I was super seeding a rather big file and it wasnt using all of my upload bandwidth, going at like 5k total upload. I let it go for a few hours and went to work and came back i was only connected to 3 peers even though there was like 15 on the torrent. Ill seed another file so i can show you what im talking about..

Link to comment
Share on other sites

i can confirm superseed is broken

i start seeding a new torrent and the upload maxes out at whatever i limit it at (70k for example) then i right click and enable superseed, and then utorrent drops all connections and restarts seeding (superseed on) then the upload speed will start fluctuating like crazy but when i disable superseed it jumps right back up to 70k i will try to get a pic up

Link to comment
Share on other sites

I understand the idea behind Super-Seeding, but I believe it could be tweaked to allow better use of available bandwidth. For example, instead of each peer getting a single piece and waiting for him to upload it to others (which can take time), each peer could be given 5 random pieces.

That way, while μTorrent waits for a piece to show up elsewhere, the peer can still be downloading another piece.

I do believe that super-seeding needs to be improved to be more bandwidth efficient.

Conversely, I thought of another method of super-seeding. μTorrent would still act as a normal 'seed'. A peer could request a piece, which uTorrent would then mark as 'sent'. If another peer requests the same piece, μTorrent would ignore the request and choke the peer. In other words, μTorrent would only send each piece out once, but it would allow the peers to make the request instead of 'assigning' them a piece.

Link to comment
Share on other sites

Isnt that the way it works now ? I dont think we just send pieces out to peers without them requesting anything.

The standard Super-Seeding implementation works like this:

(1) When the client connects to a peer, it tells the peer that it has 0.0% of the file complete (no pieces)

(2) The client 'assigns' a piece to a peer by sending a "Have Piece #" message. Since the peer believes that piece is the ONLY piece you have (and it doesn't have it), that peer will send a "Request Piece #" for that piece.

(3) The client waits for that piece # to appear in other peers (they will send "Have Piece #" message to the client). At that point, the original peer will be sent another "Have Piece #" message with a new piece.

The efficiency is that each piece is only sent ONCE (to 1 peer, who then sends it to other peers). The INEFFICIENT part is the WAITING GAME that the client does.

If you use Azureus in Super-Seeding you can see this in action. You'll see that the upload speed to a peer will increase until the peer nears finishing the piece, then it will drop to 0kb/s. A new piece will be assigned and the peer's speed will pick up again. All that down-time could be better used, for example, by giving a peer more pieces to download at once.

The point of Super-Seeding should be to maximize upload bandwidth (lowers total seeding time) while minimizing the amount of data sent to allow the swarm to complete the download.

Link to comment
Share on other sites

When superseed is on, uTorrent sends only a single piece to all others peers. So as soon as a peer has downloaded a piece, that peer won't get anymore data until the piece has been found on other peers.

I'm not quite sure how superseed is suppose to work, but wouldn't it be better to send a different piece to each peer at least?

The idea of only sending one piece to a peer at a time is also to prevent big leechers I think. They won't get another piece if they don't upload or if they have slow uploads, the pieces will go to the peers with faster uploads as they'll send it to another peer sooner.

Link to comment
Share on other sites

Isnt that the way it works now ? I dont think we just send pieces out to peers without them requesting anything.

The standard Super-Seeding implementation works like this:

(1) When the client connects to a peer, it tells the peer that it has 0.0% of the file complete (no pieces)

(2) The client 'assigns' a piece to a peer by sending a "Have Piece #" message. Since the peer believes that piece is the ONLY piece you have (and it doesn't have it), that peer will send a "Request Piece #" for that piece.

(3) The client waits for that piece # to appear in other peers (they will send "Have Piece #" message to the client). At that point, the original peer will be sent another "Have Piece #" message with a new piece.

The efficiency is that each piece is only sent ONCE (to 1 peer, who then sends it to other peers). The INEFFICIENT part is the WAITING GAME that the client does.

If you use Azureus in Super-Seeding you can see this in action. You'll see that the upload speed to a peer will increase until the peer nears finishing the piece, then it will drop to 0kb/s. A new piece will be assigned and the peer's speed will pick up again. All that down-time could be better used, for example, by giving a peer more pieces to download at once.

The point of Super-Seeding should be to maximize upload bandwidth (lowers total seeding time) while minimizing the amount of data sent to allow the swarm to complete the download.

Thank you for that explenation, I've wondered how super-seed is supposed to work (or in this case, don't work) and you explained it nicely. Absolutely no use for super-seed then :(

Link to comment
Share on other sites

It works great where it was made to work. Initial seeding or lone seeding.

Not really, every torrent I've seeded has given extremly bad speed with super-seed vs. normal (lone and initial seeding both). It's using about 20 of 150kb/s

Link to comment
Share on other sites

Precisely. Super-seeding isn't something you should use routinely, it is for very very specific circumstances and even then it might not be what you want to use.

If the super-seeding is implemented properly in the client, and nobody is saying it isn't here that I can see, then this discussion should go no further. Just don't use super-seeding if you don't want it - clearly people can seed just fine and at high speeds using normal seeding.

Link to comment
Share on other sites

Super-seeding, if I'm not mistaken, was never about "fast" upload, but fast distribution. Of course you're going to be uploading slower since you're not accepting as many connections (since you're selectively uploading pieces).

And fast distribution is supposed to be slow? :) Contradiction of the day ;)

And yeah, if it's working as it should, there's no reason to keep this thread going.

Link to comment
Share on other sites

No, it's not a contradiction.

Fast upload means uploading at a fast rate, but that doesn't mean it's widely distributed or spreading quickly. You might be uploading identical data to multiple people, and that's why you're uploading at a higher speed. Problem with that is that the data isn't getting spread out, so everyone might have the same exact pieces completed. But super-seed GUARANTEES that everyone gets a different piece. Meaning everyone has to get in line to get a piece from you.

Link to comment
Share on other sites

When super-seeding is off, and you're the only seed, you're more likely to see that you've uploaded well over the size of the torrent and still don't have a full copy of the file distributed to the peers. Super-seeding mode helps reduce the amount you need to upload before a full copy is distributed, AND makes sure the peers who share the most/have the fastest upload have the most unique pieces, which speeds up the swarm as a whole.

Link to comment
Share on other sites

µTorrent is uploading a lot slower because it's not accepting every single request. It's sending data based on what it thinks should be sent in order to improve the distribution of the torrent as a whole.

Read the official information on it here.

I can't seem to find any "benchmarks" on it, but I can tell you that the theory and implementation isn't wrong.

Link to comment
Share on other sites

µTorrent is uploading a lot slower because it's not accepting every single request. It's sending data based on what it thinks should be sent in order to improve the distribution of the torrent as a whole.

Read the official information on it here.

I can't seem to find any "benchmarks" on it, but I can tell you that the theory and implementation isn't wrong.

I'm not arguing the theory (everything works in theory), I just want to see some reality to it :) Especially in real world environments with client disconnections, different client software, the efficency in small vs large networks (5 vs 5000 peers ex) and if it's just bandwidth that's saved or if the time saved is proportional too.

All in all a very interesting method to distribute data :)

Link to comment
Share on other sites

Not had the chance to test it with uTorrent yet but here's my experience:

On a well run private tracker typically in normal seed mode I need to upload 120 to 130 percent to get a completion.

Superseed cuts this to as low as 102 percent - BIG difference. Of course this is no use if it can't max out your upload bandwidth.

I normally run with 4 peer connections per torrent (on a 256kb/s upload speed). To superseed I increase this to 8 connections. (Use a higher number still if your connnection is faster than mine.) Allowing more connections gets over the downtime and lost speed as the client waits to see already sent pieces in the swarm.

The only client I ever got to fill the available bandwidth in superseed mode was Tornado and using 8 connections it will max out the bandwidth. It is always a little bumpy when first starting out, but once you have over 10 leechers in the swarm it will be running fine.

Azureus superseed on the otherhand could not be made to run fast enough by any method.

Link to comment
Share on other sites

My point was that FAST upload speed and FAST distribution don't have to be mutually exclusive. I fully believe that someone could come up with a more efficient lone-seeder algorithm than the one implemented by Azureus or other Super-Seeding clients.

I don't believe that the existing method is the ONLY or even the BEST method of initial seeding.

I wish someone would sit down and try to work out a more efficient method without being stubborn.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...