Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 450875 - RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
Summary: RFE: yum-fastestmirror should detect bandwidth, not just responsiveness
Keywords:
Status: CLOSED DUPLICATE of bug 484371
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: rawhide
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-11 15:03 UTC by Rob Taft
Modified: 2014-01-21 23:03 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-23 18:18:33 UTC


Attachments (Terms of Use)
poll by download speed of repomd.xml (deleted)
2008-12-25 09:56 UTC, Izhar Firdaus
no flags Details | Diff

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):
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 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 ***


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