On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote: > ]] Marvin Renich > > * Tollef Fog Heen <tfh...@err.no> [151207 00:17]: > > > ]] David Kalnischkies > > > > [And before someone complains about PDiff being slow in apt based on > > > > some years old experience: The PDiff handling was changed nearly two > > > > years ago… – and apt-file was using PDiffs before already, so no real > > > > change there] > > > > > > Does this mean apt now will only download a single file, regardless of > > > whether it's grabbing the updates a pdiff or full packages file? In the > > > past, the problem for me has been that you end up being latency-bound, > > > rather than bandwidth-bound. > > > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > > this (or something near this) wasn't the default from the start, I don't > > know. The current default is an extremely poor choice. Perhaps someone > > should file a bug (serverity critical :-P) to get the default changed.
Of course, setting it to 3 makes sense only for people who run 'apt update' at least every 24 hours (3 files = 3 dinstall runs, each run is currently 6 hours apart) as otherwise apt would be forced to download the entire file again. And even for those it makes probably no sense at all, but okay lets see: I somehow can't believe that downloading a few kilobytes split into multiple files is slower than downloading the entire file and I said that multiple times already on public record – the last time I even presented it live in my debconf talk where I was downloading 2+1 releases (sid and testing which have pdiff, stable which hasn't) * 4 architectures * ~ 3 days of no updates (aka ~12 pdiffs per file) amounting to ~150 pdiffs files first with pdiffs and a second time without and pdiff was still 10% faster (beside saving a whole lot of bandwidth and traffic of course). And that just involved small files like Packages – Contents are roughly 10x bigger, so you must have got a pretty great network, sir, as I believed the DebConf network was already pretty great with its local mirror on site to download everything from… btw: The default for apt-file which wasn't effected by this apt setting at all [of course] was 50 – that is close to two weeks of pdiffs. Somehow, that seemed to be fine for you. Just saying. If I had any gamble money I would put an unholy amount of it on "I tried pdiffs many years ago and assume nothing has changed since then"… That idea is right on par with the idea that "apt and aptitude are incompatible": Utter nonsense of course, but an invincible zombie-idea and the reason why I made that initial []-comment. > I believe this has already been discussed, but what you really want is > to do reverse diffs from today to dates in the past, not incremental > diffs in the other direction. Good news then: apt-file didn't support this at all, apt does just fine since ever. The problem with server-merging is just that the server has to do it, which is why apt is doing client-merging for nearly two years now (apt-file did it since ever) by default, but apt happily works with server-merged as well, just add "X-Patch-Precedence: merged" to your .diff/Index file [reprepro is the only server tooling I knew of which did server-merge and used that field to indicate it]. From the client side, I would like to get pipelining back for pdiffs, which currently is auto-disabled for them as apt can't detect pipeline messups without hashsums and pdiffs currently haven't [0], but if we have it, it should help in high latency situations (beside improving security which is the real reason I want it). If you have other ideas feel free to suggest them. Best regards David Kalnischkies
signature.asc
Description: PGP signature
