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 :-(
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
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
fedora/primary_db | 14 MB 00:01
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.
The "skip to next mirror" feature is gone (we don't want to restart all
currently running downloads).
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
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.
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
(21/485): binutils-220.127.116.11.1-10. (1%) 16% [==== ] 9.6 B/s
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 !
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
python-urlgrabber-3.9.1-21.fc18 has been submitted as an update for Fedora 18.
python-urlgrabber-3.9.1-17.fc17 has been submitted as an update for Fedora 17.
python-urlgrabber-3.9.1-18.fc17 has been submitted as an update for Fedora 17.
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.