Does too many peers make it impossible to seed?

[ssih]

Mop Girl ep06 (1280x720 DivX6).avi has been sitting there with nearly half a gig missing, no seeders, and 27 other peers. So I was wondering...

With all of us short nearly half a gig, what happens if some kindly seeder gets online? How much intelligence is built into the seeding process? He doesn't have to give part 1 to everyone, then part 2 to everyone, right? How would this not take forever once a seed joins us?

[eye]

Whether there are 2 or 27 or 270 peers doesn't make a difference. The average download speed for each peer will be the sum of all upload speeds divided by the number of downloaders. For example, if each peer uploads at 50 KB/s, everyone will download at 50 KB/s too. The number of peers is irrelevant.

[ssih]

So you're saying that if all 27 peers could upload at 50Kbps and one seeder came on (also capable of 50Kbps), then all 27 of us would see that file downloading (and uploading elsewhere) at approx 50Kbps?

[Boulayman]

I don't really agree with what eye says, after the torrent has been running for a while then yes it's true but I would think that to start off the torrent having too many peers make it far harder for the seed. Imagine a file has 280 pieces and there are 28 peers. What eye says is only true if at any given time all the 28 peers have simultanously at least 28 different pieces. If not, assuming the 28 peers only have 14 pieces and each has a 50 up speed, then there will be extra pressure on the seed from at the veyr least 14 peers since half of them have nothing to upload but need to download...

As for the intelligence in the seeding process I would say it's pretty smart and tries to avoid the above situation from happening BUT you gotta see that there are other variables that make it far harder for the seeding process to manage it very efficiently: very different upload speed from a peer to another some peers don't seed after they're done some peers change their mind and cancel the download before it's over...

[ethidda]

On d-addicts, yes, it's hard for the seeder, because many people here have ADSL or other reason for limiting their upload speeds to be significantly lower than their download speeds.

In an ideal situation, the number of peers doesn't matter. They would all upload at least as much as they download, so the seeder only has to upload a little bit over one full copy in order for the peers to be able to complete the files eventually. My experience on d-addicts has been that I need to seed a file at least 3-6 times over before it will survive for any length of time. This is not how bittorrent communities are supposed to work, but it seems to be how it is at d-a because of people inability contribute back to d-a.

[ssih]

I don't understand how the process works, or how intelligent the dissemination of data is set up. It would be nice if the following scenario occurs:

Ten peers are all waiting for 100 parts to a file. The seeder comes online and:

uploads parts 1-10 to peer #1
then
uploads parts 11-20 to peer #2
then
uploads parts 21-30 to peer #3
...etc.

I'd think that this would allow all of the peers to take a more active role in the sharing.

[Issy]

i have noticed that if there is only one seeder, it does makes so much difference with dling. when i dl dramas one to one from a seeder and its only me, it always takes long time with very low speed (even though i have a fast broadband). even when there is other peers around, nothing changes much too.(if all are in the same level of dling)
i also noticed that having too many peers and only one seeder is still a big help to my dl specially if they are much higher in % of their dl than me and as soon as i get to everyone's %, it slows down again. that is why i always wait when there is more than one seeder is around.

[ethidda]

Bittorrent works like this. If there are peers a, b, c, d and seeder e. Then, peer a would first ask b, c, d, and e which pieces they have. When a asks for a piece it's determined in the following way:

- it asks for a piece a does not have but the one it asks has
- if there are differences in priority, it chooses one with the highest priority
- it asks for a piece that there are the fewest copy that it sees that fit the above criteria

So, for example, a would only ask e for pieces that only the seeder has, unless there is already at least one complete copy between all the peers. a would ask b for pieces that there are only two copies of (e and b), or if there are no such pieces, then a piece that only three copies exist (e and b and something else), and so forth.

The only time when transfer might not be optimal is if e is already uploading piece #n to b, but because b does not have the complete piece, a sees #n as a piece that only e has and also asks e to send it #n as well. However, the peers ask for random pieces that fit the above three rules, so this is unlikely to happen unless there are only few pieces for which there are a minimal number of copies, in which case, it does not make an appreciable difference.

The problem with the algorithm ssih stated above is that peers and seeders cannot always see or connect to each other. Furthermore, more peers may join or leave the torrent at any time, meaning that if an 11th peer joins in the scenario above, either the seeder has to now download different pieces, or it becomes increasingly difficult to decide which pieces the newest peer gets. Furthermore, if a second seeder joins the scenario but cannot connect to the first seeder to figure out the upload scheme, then it becomes even more of a mess.

Smart random distribution is by far the best method.

[eye]

If not, assuming the 28 peers only have 14 pieces and each has a 50 up speed, then there will be extra pressure on the seed from at the veyr least 14 peers since half of them have nothing to upload but need to download...

The pressure on the seed remains constant all the time. And usually it needs to upload each chunk only once, no matter how many peers are present. Of course there is some latency until the chunks trickle down to the last peer, but BitTorrent chunks are reasonably small, so the peers can start uploading quickly. Latency was a much bigger problem in the ED2K network with a constant chunk size of 9 MB.