You are not logged in.
Beginning a few weeks ago, pacman on my office computer suddenly became very slow to download. pacman would report a download speed starting at around 100K/s and dropping exponentially to a few B/s. On the larger databases (i.e. extra.db) it timed out with a message like
error: failed retrieving file 'extra.db' from lug.mtu.edu : Operation too slow. Less than 1 bytes/sec transferred the last 10 secondsThinking it was a bad mirror, I tried changing mirrors, ultimately switching to a mirror that was working very nicely on my home computer, but still had the same timeouts and/or slowness. I tested other downloads, e.g. of several hundred MB using wget and the speed was normal (around 1MB/s). The only symptom I've found is in pacman.
I concluded that the slowness is not the fault of the mirror nor of my network connection. It seems to be something particular to how pacman accesses the network, and it probably indicates some underlying issue in my networking setup.
Searching this bbs and googling generally, I found advice to use the XFerCommand option in pacman.conf to use wget. This enabled the downloads to complete, albeit very slowly.
I also found advice to disable ipv6, though without any reason given why this should help. This seems like risky advice and a hack, rather than determining what the underlying problem is.
I tried pacman -Syyu --debug, but there was nothing unusual in the output.
I've also checked my networking setup pretty thoroughly, though I suspect I'm missing something here. eno1 is my wired device. I'm using systemd-networkd for my networking. Here's my routing table:
$ ip route
default via 10.1.2.1 dev eno1 proto dhcp src 10.1.2.100 metric 1024
10.1.2.0/24 dev eno1 proto kernel scope link src 10.1.2.100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-83422f496d52 proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-d3717b55b7e5 proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/16 dev br-aaf722e410b8 proto kernel scope link src 172.20.0.1 linkdown
172.21.0.0/16 dev br-feaaa47f6462 proto kernel scope link src 172.21.0.1 linkdown
172.22.0.0/16 dev br-506b1d1d9c60 proto kernel scope link src 172.22.0.1 linkdown
172.23.0.0/16 dev br-e6691d487aa0 proto kernel scope link src 172.23.0.1 linkdown
172.24.0.0/16 dev br-cc1dc40b8a45 proto kernel scope link src 172.24.0.1 linkdown
172.25.0.0/16 dev br-47655353173a proto kernel scope link src 172.25.0.1 linkdown
172.26.0.0/16 dev br-9d9e5716b95f proto kernel scope link src 172.26.0.1 linkdown
172.27.0.0/16 dev br-7012a0e1573e proto kernel scope link src 172.27.0.1 linkdown (the extra 172.x.x.x routes are for docker; all the links are currently down, so it's not that.)
So first, I am wondering why disabling ipv6 might help, and what that might imply about the networking setup if it does help; and second, what else might I do to get pacman back up to speed again.
Thanks in advance.
Offline
You tried to set the xfer command to wget and you still have the issue? This is weird. Can you try to download the exact same package with wget directly with the exact same mirror and protocol (ftp servers often cause more problem than http server even if they run on the same physical machine) and see what happens?
The problem you describe is usually a bad mirror or network. An ipv6 problem would have the same effect with wget via te xfer command or wget by hand. Be careful in your test to choose the exact same server, package, and protocol. Prefer http or https server to ftp server.
It would be useful to post your server configuration as well as the exact command you have tried by hand.
Last edited by olive (2017-04-26 09:06:23)
Offline
Thanks for the assist.
To be clear, when I set the XferCommand to wget it did complete the download, but it remained very slow.
I'd read the advice to prefer http(s) over ftp and have only used http servers during this period.
Here is my pacman.conf. The only change I made was to uncomment the XferCommand for wget:
#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives
#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
#GPGDir = /etc/pacman.d/gnupg/
#HookDir = /etc/pacman.d/hooks/
HoldPkg = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta = 0.7
Architecture = auto
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg =
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
# Misc options
#UseSyslog
#Color
#TotalDownload
CheckSpace
#VerbosePkgLists
# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required
# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.
#
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
# - URLs will have $repo replaced by the name of the current repo
# - URLs will have $arch replaced by the name of the architecture
#
# Repository entries are of the format:
# [repo-name]
# Server = ServerName
# Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#
# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.
#[testing]
#Include = /etc/pacman.d/mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
#[community-testing]
#Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.
#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist
#[multilib]
#Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgsI've run the test you suggest. Here is a comparison between using pacman (XFerCommand is wget) and wget directly for a few of the bigger databases/packages:
http://mirrors.lug.mtu.edu/archlinux/ex … 4/extra.db: pacman 52s; wget 29s
http://mirrors.lug.mtu.edu/archlinux/co … mmunity.db: pacman 66s; wget 85s
http://mirrors.lug.mtu.edu/archlinux/ex … pkg.tar.xz: pacman 96s; wget 107s
http://mirrors.lug.mtu.edu/archlinux/co … pkg.tar.xz: pacman 117s; wget 128s
So the results are pretty similar, which quite possibly indicates a wget + ipv6 problem. In general, I'm seeing speeds of order 60 KB/s this morning.
I tried the same file/mirror on my home machine (machine/network with no issues) and found 8.4s for wget of the last (pandoc) file. So the mirror seems OK. I'm seeing speeds of order 1MB/s at home and 60KB/s at the office, more than an order of magnitude different.
I tried another large, non-pacman file: https://download.jetbrains.com/idea/ide … 1.2.tar.gz. Using wget at home it took 81s and at the office it took 189s. Speeds were 6.45MB/s at home and 3.10MB/s at the office, so a factor of 2 different. This is roughly in line with the expected network speeds (home optimized for downloads, office is static IP with equal up/down speeds).
So pacman (method wget) and direct wget both see similar (abnormally slow) speeds in the office, which is about a factor of 20 slower than at home. wget of a different large file sees reasonable speeds both in the office and at home, with the office a factor of 2 slower than at home (to be expected).
Does this help isolate whether it's ipv6 causing the problem? Why would ipv6 matter for the pacman mirrors but not for a different large download?
I am going to try disabling ipv6 in the kernel (temporarily) to see if that resolves the issue, just for the sake of debugging, but if ipv6 is really the issue, I'd like to understand why and how I can fix it, rather than disabling it.
Thanks again.
Offline
You experience the same problem with wget and pacman, so this is not a pacman problem. When you say "at home " or "at the office" are you using the same machine? The observed speed between point A and point B depends on the whole network between A and B, not necessarily A or B alone. There are a lot of possible Archlinux mirrors. if you can connect with a normal speed to some servers, chances are great that you will find a mirror that works well for you. If not, then your ISP is probably the culprit.
I don't think ipv6 has anything to do with these kinds of problems (but you can always try to disable it). Do wget connect with ipv6? what's the output of wget? Note that you can force wget to connect with ipv4 (or ipv6) with the "-4" or "-6" option (see man wget). But as I said, I doubt ipv6 is the culprit. Why do you think it is?
Last edited by olive (2017-04-26 12:41:38)
Offline
These are different machines on different networks, both running Arch Linux. They are in the same geographical location roughly.
I disabled ipv6 on the office machine (added a kernel parameter ipv6.disable=1) and rebooted, verified that ipv6 is disabled (no ipv6 addresses shown under ip addr) and still get slow download speeds, more or less in line with what I reported earlier. So I agree, it is not an ipv6 issue.
I also tried another mirror, Server = http://mirror.us.leaseweb.net/archlinux/$repo/os/$arch. I saw even slower speeds in the office (326s), but it was nearly instantaneous (0.3s) at home.
One thing that is striking is that wget initially reports a reasonable speed, a few hundred KB/s, but then rapidly trails off toward a few KB/s and sometimes shows --.- KB/s. Then jumps again to a few dozen KB/s and exponentially drops off again.
I tried pinging this mirror; I get 45ms from the office and 40ms from home, both with no dropped packets and very low mdev.
I tried downloading few other large files from various locations and again got a speed of a few KB/s from the office and 10.5MB/s from home.
I tried downloading the same extra.db file using wget on a different machine in the office (running Ubuntu FWIW) and got a download speed of 5MB/s.
In summary:
* The problem is not only with pacman, but may be particular to how the mirrors are transferring the files since I see some non-mirror servers that are more normal.
* The problem is not with the office network since a different machine in the office sees a very high download speed from the same mirror.
* The problem is not ipv6 since the problem machine sees the same slow download speeds even with ipv6 disabled in the kernel.
* The problem has to be with the network configuration of the problem machine, it's just exacerbated with pacman's mirrors.
So this isn't really the proper forum for this issue--I initially posted here because pacman was the most problematic symptom and I'd seen unexplained advice that disabling ipv6 could resolve slow pacman speeds, but didn't want to take that step without understanding why. I will try to start from scratch on my networking setup and see if I can figure anything out. Thanks a bunch for your help, it's great getting some troubleshooting advice.
Offline
I don't think your setup is in cause. I have often experienced these kinds of slowdowns (that goes slower and slower for big download) in the case of congested networks. The connection time is not really relevant. Anyone can become an Archlinux mirror with an http server, there is nothing Archlinux specific here. As I said if you are able to download a big file rapidly from some servers, you will eventually find a mirror that works well, if not your internet provider is most likely in cause and there is nothing to do.
Last edited by olive (2017-04-26 13:15:11)
Offline
OK, thanks for the help. Cheers.
Offline
Holy cow--turns out it was of all things my UPS. I was passing my ethernet through it for surge protection and it was introducing noise. I don't know why downloading some other files didn't seem slower--I guess it was just coincidence.
Glad I figured out it was the simple solution before I rebuilt my machine...
I'd like to change the title of my post since it turned out to be not "only pacman" causing the problem, but can't see how to do that.
Offline
Holy cow--turns out it was of all things my UPS. I was passing my ethernet through it for surge protection and it was introducing noise. I don't know why downloading some other files didn't seem slower--I guess it was just coincidence.
Glad I figured out it was the simple solution before I rebuilt my machine...
I'd like to change the title of my post since it turned out to be not "only pacman" causing the problem, but can't see how to do that.
You had passed the internet signal through the UPS??? I thought these devices were for the electricity only. To change the title of your post, just click the "edit" field on your initial post and change the title. Be careful however as the answers you received concerned the initial post, changing the post or the title afterward could disturb the reading of the thread by making some answer inappropriate. Take in mind that these forums can be read afterward by someone looking for an answer to his problems.
Last edited by olive (2017-04-26 15:30:51)
Offline
Well, the UPS has ports for ethernet and phone to protect them--we get lots of lightning in Florida. The UPS is only about a year old and this problem only started recently, so apparently a recent power outage must have messed up its noise filtering.
I wanted to change the title precisely to make it more helpful for other readers--I searched for quite awhile for help with only pacman and pacman + ipv6, so in the end this post isn't that helpful for that problem. I'd been hoping to come to understand why turning off ipv6 might help with pacman speed issues! But OK, I'll just leave it unedited.
Offline