Bug 450875

Summary: RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
Product: [Fedora] Fedora Reporter: Rob Taft <rrtaft>
Component: yum-utilsAssignee: Seth Vidal <skvidal>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: aleksey, amcnabb, ffesti, james.antill, katzj, matt.castelein, pmatilai, tim.lauridsen
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-23 18:18:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
poll by download speed of repomd.xml none

Description Rob Taft 2008-06-11 15:03:47 UTC
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):

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
Actual results:

Expected results:
the fastest mirror

Additional info:

Comment 1 seth vidal 2008-06-11 17:28:18 UTC
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.

Comment 2 Izhar Firdaus 2008-12-25 09:56:06 UTC
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 ..

Comment 3 Andrew McNabb 2009-04-23 17:33:06 UTC
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.

Comment 4 James Antill 2009-04-23 18:18:33 UTC
 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 ***