On 2013-09-06 15:02, Helmut Grohne wrote: > Thanks for your explanations! > > On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote: >> As this suite is much smaller than the full archive, updating it can be >> done with much less overhead and is done with every cron.unchecked >> run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180 kb compared to >> 8.5 MB each for the main archive. There are also no Contents indices. > > One aspect I couldn't find in the discussion so far is reduction of > bandwidth on *my* end. Let us for a moment consider a user to run sid > with incoming enabled and the dinstall frequency cut in half. Are the > following conclusions correct? > > * [...] > * If PDiffs are enabled, I assume that incoming would not support > PDiffs for its rapid rate of change. With PDiffs the number of diffs > is interesting, because processing them usually is the limiting > factor here. The number of PDiffs would be halved as well here, so > the update would usually go faster. > > [...] > > Who hasn't disabled PDiffs, because they take way too long when the > network is fast? >
Well, most of the problem with PDiffs could actually go away if made a (to me seemly) minor change their index files. If it is possible to determine the "outcome" of applying a PDiff, APT could apply the diffs in a much more efficient manner. Currently, apt-file does this by making assumptions (which holds for DAK produced PDiffs atm, but not for - I think - reprepro). So if "runtime of using PDiff" is your concern, I think "fixing" PDiffs would be a much more interesting solution than working around it by halfing the number of dinstalls (although, I don't have particularly strong opinions in regards 2 vs 4 dinstalls per day). For those interested, I believe #703366 might be worth a read on that topic[1]. >>From this very limited POV the proposal appears to be an improvement. > > Helmut > > ~Niels [1] e.g. <201303201830.32577...@sfritsch.de> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5229d53c.4020...@thykier.net
