Bug 450875 - RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
Status: CLOSED DUPLICATE of bug 484371
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
rawhide
i386 Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 11:03 EDT by Rob Taft
Modified: 2014-01-21 18:03 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 14:18:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
poll by download speed of repomd.xml (1.72 KB, patch)
2008-12-25 04:56 EST, Izhar Firdaus
no flags Details | Diff

  None (edit)
Description Rob Taft 2008-06-11 11:03:47 EDT
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:
Comment 1 seth vidal 2008-06-11 13:28:18 EDT
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 04:56:06 EST
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 13:33:06 EDT
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 14:18:33 EDT
 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 ***

Note You need to log in before you can comment on or make changes to this bug.