[Bug 1794957] Re: pipelining on archive.u.c aborts after 101 packages

[Julian Andres Klode]

Here is a short graphical comparison of before/after in the bionic SRU
in a container. I modified the container's network bridge to add 300ms
delay using

sudo tc qdisc add dev lxdbr0 root netem delay 300ms

which made things quite more visible on a slower 12 Mbit/s connection.

I could clearly see that _without_ the 1.6.6 SRU, speed dropped a lot
after the first 100 (101?) packages were fetched, you could see in the
progress that it fetched one file and then started fetching the next
one.

In contrast, with the SRU installed, progress sometimes shows lines with
multiple files very quickly; i.e. it drains the entire pipe of 10 items
in what feels like one update of the progress output.

You can also see this in the pictures: In the old graph, network speed
has a sudden drop in the middle; in the second picture (which was
running a bit longer, so it starts more on the left), you see that
performance can be sustained.

** Attachment added: "bionic: network bandwidth after (1.6.6)"
   https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1794957/+attachment/5203091/+files/Screenshot%20from%202018-10-19%2015-57-57.png

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1794957

Title:
  pipelining on archive.u.c aborts after 101 packages

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  Fix Committed
Status in apt source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Downloading many packages on archive.ubuntu.com or some other mirrors seems to close the connection after every 100 or so packages. APT prior to 1.7.0~rc1 (commit df696650b7a8c58bbd92e0e1619e956f21010a96), treats a connection closure with a 200 response as meaning that the server does not support pipelining, hence disabling it for any further downloads.

  With high speed connections at higher latency, this can cause a severe
  reduction in usable bandwidth. For example, I saw speeds drop from 40
  MB/s to 15 MB/s due to this.

  The fix ensures that we continue pipelining if the previous connection
  to the server successfully retrieved at least 3 files with pipelining
  enabled.

  [Test case]
  Pick a package that would cause a large number (200/300 packages of packages to be installed). I used plasma-desktop and xubuntu-desktop, for example. Run apt install -d $package. Ensure that after the first 101 packages the progress does not slow down - you should not see a lot "working" in the progress output. The speed should be substantially higher.

  Don't run in a container setup by cloud-init, as cloud-init disables
  pipelining; or remove /etc/apt/apt.conf.d/90cloud-init-pipelining (see
  bug 1794982).

  Requirements:
  * High speed, medium-high latency connection (e.g. 400 Mbit/s at 30 ms RTT is enough); or just increase latency, e.g. 
     sudo tc qdisc add dev wlp61s0 root netem delay 300ms
   until you see the slow down
  * Not a terribly slow CPU, as we'd get slowed down by hashing otherwise

  [Regression potential]
  This fix is isolated to code enabling/disabling pipelining on subsequent connections. It could cause more pipelining to be tried on servers who are not particularly good at it, but can deal with 3 items correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1794957/+subscriptions