[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

>>From this very limited POV the proposal appears to be an improvement.
> Helmut


[1] e.g. <201303201830.32577.sf@sfritsch.de>

Reply to: