= bug description = Right now, and a few nights ago, but not times in between, my downloads for Fedora 20 updates were very slow. Usually less than 1kB/s (not quite 0). = bug analysis = I'm in Canada. That might affect what mirrors are being chosen.
I tried with Rogers Cable broadband and with Telnet Communications ADSL, so it isn't my last mile.
I changed /etc/yum.repos.d/fedora-updates.repo to use baseurl instead of metalink lines and the speed went up to something like normal.
At least some of the time, tcpdump listed the packets as coming (slowly!) from fedora.mirrors.pair.com = fix recommendation = Not sure. Figure out if a particular mirror is having problems? How can I tell which mirror is being used?
I've been able to improve downloading by: sudo /sbin/iptables -I INPUT 1 -s 216.92.2.158 -j DROP
yum gives up on the now-totally-silent repo and all is fine.
I wonder why the mirroring system wants me to use what appears to be a German repo.
Can you tell us from which IP address you are coming.
Maybe also the output of
curl 'https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=x86_64'
to see the mirrorlist you get.
I tried two IP addresses on my end: 99.226.29.0, 209.161.207.149, same behaviour.
I just tried yum update again, 8 hours later, from another machine on my LAN. No iptables filter.
Slow to download updates/20/x86_64/primary. A snapshot shows 221 B/s | 114 kB 698:04 ETA
tcpdump shows fedora.mirrors.pair.com being used.
I will attach a mirrorlist. I don't see pair.com in the list.
output of curl 'https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-20&arch=x86_64' mirrorlist.txt
fedora.mirrors.pair.com is listed as mirror for updates:
curl 'https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f20&arch=x86_64'
I am putting the maintainers of fedora.mirrors.pair.com on CC, maybe they can comment on why the mirror is slow for you.
hugh: Last night all of Canada that went through Hurricane Electric (HE) was completely hosed. While I got 5Mbps to speed test sites in Ontario, I got 10kbps to Europe with a 240ms roundtrip time.
My guess is that there were no Canadian mirrors that did not somehow depend on HE connectivity, or that another big outage caused the additional load on HE.
Paul:
That could explain slow fedora.mirrors.pair.com. I guess that I should have done a traceroute.
But remember that I got good bandwidth when I blocked all packets from fedora.mirrors.pair.com.
So, are things back to normal now? Or still slow?
Right now things are fine (tested on one computer). But I think that the problem has been intermittent so this observation isn't conclusive.
Did anything get fixed?
No, there's been no changes on our end for mirrormanager.
So, I guess we can wait for this to happen again and gather more info? traceroutes to the mirrors involved?
Please reopen if you see this again... thanks.
216.92.2.158 pcap slowmirror.pcap
216.92.2.158 traceroute slowmirror.traceroute
216.92.2.158 ping slowmirror.ping
I'm also seeing trouble with this mirror. Connectivity (ping/traceroute) looks fine, but I was seeing download speed vary from 200 B/s to 1.4KB/s after a while. yum was getting kernel-headers, which is fairly big, and the majority of it came down at good speed (yum's threads were maxxing out my 7Mb DSL) but then it slowed to a crawl. I needed about 800 updates and this is the only one that had trouble. Seeing as this IP has been previously reported as having trouble, it seemed worth following up.
Separately, this is probably something yum should detect - perhaps the oscillating speed was foiling yum's slow-mirror logic? I was wishing for a key I could press to disconnect the download and try the next 'fastest-mirror'. In theory we shouldn't care if a mirror suddenly becomes slow (cest la vie), just move on to the next one.
Attaching pcap, traceroute, and ping output.
Is there still an issue here?
I'm going to close this now.
Please file a new ticket if there's anything further we can do.
Login to comment on this ticket.