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
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).
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-2.22.52.0.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 ! Daniel
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. https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-21.fc18
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
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
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.