On Mon, 2009-06-01 at 11:47 -0400, Bill Davidsen wrote: > Everyone seeds for people, the server should not be seeding more than 1-2 > clients, who then seed other, and others, leaving the server to do only bookkeeping. This is the classic torrent problem, particularly with rapid torrents. If we get the bits to the torrent server (which takes a while in itself from place of creation to place of torrenting isn't the fastest link), then launch the torrent, now what? There is exactly 1 seeder, the torrent server. So you're going to have lots of clients jumping on that torrent and they're all going to be fighting for the tiny bit of bandwidth that server will have left, to get little bits out there. The clients can share those little bits that they're hopefully getting in a random pattern from the server, but inevitably they will all wind up at the same % done, and all still waiting on the torrent server. Our torrents only really perform well /after/ a number of people have successfully downloaded and are now seeding the torrent storm. When we're dealing with one or multiple RCs a day, there is no chance for this to scale. > > > If you have a real proposal here, I suggest you write it up as a wiki > > page and bring it to the attention of mroe than just the test list. > > > At the moment I'm locating pieces to have a proposal which is based on using > existing parts rather than starting with a blank screen. And it feels as though > discussion of a lower overhead means of propagating rapid changes is on topic > here, since people trying new software tend to see a higher rate of upgrade than > people using a more stable version. > > I get the impression that jigdo is out of favor for some reason, but it does > what I had in mind, allow the end user to create an install media as often as > needed, and just upgrade the jigdo file and go. If the jigdo control file > created a dated ISO image, it could be updated very regularly. And if editing > the jigdo file were easier people could add their own list of non-default > packages if they were creating a 8.5GB image. > > It appears to be as easy as updating the jigdo file, which may be done already > if you do internal daily (or frequent) install media creation for testing. > > There, that didn't take a wiki page, all it needs is a comment on the state of > the tools needed. Jigdo is out of favor mostly because it's an end user UI nightmare. It's a really terrible program to try and use effectively. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
