On Sun, 2008-10-12 at 11:26 +0200, Denis Leroy wrote: > Mike McGrath wrote: > > I'll have a talk with Jesse. For the normal releases we typically have > > multiple seeders from the start. For these sorts of snapshots I suspect > > some steps can be taken to ensure better usability here. I talked with > > Seth a bit about this too (he's our current torrent wrangler) and we > > generally think this was just an issue with two many chunks and not enough > > people for chunks from the beginning. Which is self correcting but A) > > is annoying and B) is preventable in the future. We just have to figure > > out the procedure on it. > > I'm not convinced by this explanation. If you know a little bit about > the bittorrent protocol, the scenario of a fast uploader and about 40 > downloaders is literally a textbook example where bitorrent behaves at > its best. Yet the algorithm broke down fairly quickly, as though the > server pushed the chunks in linear order. That or something on the > network got in the way. Any followup on this? I doubt it's the protocol/algorithm. It doesn't matter what order the seed "pushes" blocks, if a seed gives a block to just one of a well connected set of "leeches", that block will quickly spread to all the others, causing them to never request that block from the seed. Bittorrent block transfers are initiated by request, not "pushed" by the seed. It's far more likely that the seed is throttled in some way, than if every one of those downloading peers are not talking to each other... I'd look for throttling somewhere near (or at) the seed. Some ISPs are getting very aggressive about throttling P2P traffic. A major backbone throttling bittorrent traffic is quite likely these days... :P
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
