Red Hat Bugzilla – Bug 450875
RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
Last modified: 2014-01-21 18:03:02 EST
Description of problem:
I am trying to do yum updates, there are many a day, and they always seem to run
around 60kB/s. I installed yum-fastestmirror so I was confused as to why this
was slow. It always chose mirror.steadfast.net. I removed the timedhosts.txt
file and ran yum again. It ran the fastestmirror tests and generated a new
timedhosts.txt, but was still picking the mirror.steadfast.net site. I reviewed
the file and it clearly has the lowest 'score' of 0.0617... When I uninstalled
yum-fastestmirror, I was able to get much faster speeds, sometimes as fast as
400kB/s, maybe more if I was looking the whole time and had the right mirror.
After reviewing the plugin code, it clearly does not test what it should. It
simply tests what server responds the fastest, which is clearly not the same as
testing bandwidth speeds which is what should matter in this case.
Version-Release number of selected component (if applicable):
It always picks the slower mirror.steadfast.net for me.
Steps to Reproduce:
1. yum update - watch the speeds and mirror it picks
the fastest mirror
You're right fastest-mirror does not check actual bandwidth.
I've changed this to an rfe instead of a bug b/c in order to get it to
accomplish this task we're going to need to change a fair number of pieces of
the plugin infrastructure in yum.
Created attachment 327835 [details]
poll by download speed of repomd.xml
a little hack of mine, which evaluate mirror by download speed of repomd.xml ..
I noticed this, too. Upgrades were going very slowly, and it turns out that yum was not using the private mirror on our subnet. Somehow it decided that a server in Germany was faster. I'm surprised how fastestmirror could have decided that the other server was faster. In terms of ping times, it was two orders of magnitude slower, and in terms of bandwidth it was one order of magnitude slower. I like the idea of fastestmirror, but with the current approach, it seems to slow down upgrades dramatically.
So there are two sides to this:
1. fastestmirror only does a connect(), not a real download.
2. fastestmirror only does a single check, for each host.
...it's possible changing #1 will help in some cases, but it will also take longer to do all the checks. Changing #2 is an open RFE, and something we want to change eventually ... which should solve the problem once and for all.
FWIW, I almost always get near wire speed without fastestmirror (probably because MirrorManager is so good) ... which is the main reason we haven't made it mandatory like CentOS.
*** This bug has been marked as a duplicate of bug 484371 ***