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): 1.1.13-2.fc9 How reproducible: It always picks the slower mirror.steadfast.net for me. Steps to Reproduce: 1. yum update - watch the speeds and mirror it picks 2. 3. Actual results: mirror.steadfast.net Expected results: the fastest mirror Additional info:
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 ***