Bug 860181 - F17: yum does not switch mirror with STRG+C
F17: yum does not switch mirror with STRG+C
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-25 04:12 EDT by Harald Reindl
Modified: 2014-01-21 18:23 EST (History)
6 users (show)

See Also:
Fixed In Version: python-urlgrabber-3.9.1-18.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-25 05:44:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2012-09-25 04:12:08 EDT
currently many feodra mirrors are TERRIBLE slow
on F16 with STRG+C yum is switching to another one
on F17 the frist STRG+C quits yum :-(

___________________________________________________________________

yum-3.4.3-29.fc17.noarch

updates-testing                                                                                | 4.7 kB     00:00
(1/5): rhsoft-fedora/primary_db                                                                | 179 kB     00:00
(2/5): rhsoft-generic/primary_db                                                               | 4.7 kB     00:00
^C/5): fedora/primary_db                     40% [==                                ]  93 kB/s | 1.4 MB     03:40 ETA

Beende nach Abbruch durch den Benutzer
[root@testserver:~]$

___________________________________________________________________

yum-3.4.3-25.fc16.noarch

fedora                                                                                         | 4.2 kB     00:00
^Cfedora/primary_db                             2% [-                                 ]  15 kB/s | 372 kB     15:40 ETA
 Aktueller Download abgebrochen,  unterbrechen Sie (Ctrl-c) erneut  innerhalb zwei Sekunden
zum Beenden.

fedora/primary_db                                                                              |  14 MB     00:01
Comment 1 Zdeněk Pavlas 2012-09-25 05:44:58 EDT
It's a feature of the parallel downloader.  There are N independent download processes running, CTRL-C sends a signal to all of them.  In theory, we could keep the original behavior when only one DL is active, but this would probably cause even more confusion.

http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/164038

The "skip to next mirror" feature is gone (we don't want to restart all
currently running downloads).
Comment 2 Harald Reindl 2012-09-25 05:53:15 EDT
the problem is that "yum-fastest-mirror" does not work at all
so i can do "yum clean metadata && yum upgrade" as often i want and do not get any acceptable speed, i am on a 100 MBit WAN at office and also at home and seeing downloads with some KB/Sek or lower is frustrating

the last days the mirrors of "tuwien.ac.at" as example are degraded down to 600 BYTE/sek and it is COMPLETLY useless to download parallel from the same mirror if it is slow, parallel downloads would only make sense if yum would spread them over DIFFERENT mirrors

i guess "parallel downloader" is one of the reasons that some mirrors are completly unuseable because much more load with no benefit at all

WHY was this implemented in the way starting parallel downloads from the same mirror? this makes absolutely NO SENSE
Comment 3 Zdeněk Pavlas 2012-09-25 07:23:49 EDT
Yes, mirror ordering from yum-fastest-mirror is now mostly ignored, /var/cache/yum/timedhosts database is used/updated instead.  As far as I can tell, in practice this works better than yum-fastest-mirror plugin.

The parallel downloader of course does use different mirrors, and avoids simultaneous connections to the same mirror- see the lengthy discussion in fedora-announce.

When a mirror becomes slow, It's "score" (estimated speed) is decreased after few downloads, and Yum then avoids it.  But if you kill a DL before it finishes, the score of the selected mirror is not updated.  

Hmm, maybe we should update mirror stats on aborted downloads, too.
Comment 4 Harald Reindl 2012-09-25 07:56:16 EDT
so what about a setting for /etc/yum.conf to try another mirror if yum is creeping below a user defined value in KB/sec for longer than 5-10 seconds

with mirrors creeping around 20 KB/sec or sometimes BYTES/sec it takes up to some minutes to even receive the repo-metadata which is frustrating if you are on a network which supports 12 Megabyte/Second
Comment 5 Harald Reindl 2012-09-25 08:01:17 EDT
(21/485): binutils-2.22.52.0.1-10. (1%) 16% [====                     ]  9.6 B/s
Comment 6 Daniel Veillard 2012-09-26 00:10:40 EDT
It's not that bad, here in China:

updates/primary_db        0% [===             ]  158 B/s | 1.1 MB 536:51 ETA

and yes there are fast mirrors, but that's changing dynamically !


Daniel
Comment 7 Harald Reindl 2012-09-26 03:57:40 EDT
it IS bad if you are sitting on business line with 100 Mbit = 12 MB/Sec
we are paying a lot of money for this line and so it would be fine if yum
is choosing a acceptable mirror instead wasting my time again and again
Comment 8 Fedora Update System 2012-09-27 06:57:10 EDT
python-urlgrabber-3.9.1-21.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-21.fc18
Comment 9 Fedora Update System 2012-11-21 03:51:58 EST
python-urlgrabber-3.9.1-17.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-17.fc17
Comment 10 Fedora Update System 2013-01-07 07:56:52 EST
python-urlgrabber-3.9.1-18.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-18.fc17
Comment 11 Fedora Update System 2013-05-31 22:25:52 EDT
python-urlgrabber-3.9.1-18.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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