Re: Less dinstall FTW?
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.sf@sfritsch.de>
Reply to: