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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
