I don't know what logic dnf uses to pick a mirror. I know yum will usually pick the first mirror of the mirrorlist, which is usually the fastest and closest mirror. When I run "yum update" I get a download speed of 1.5MB/s When I run "dnf update" I get a download speed of 50KB/s It appears that dnf is not using the first mirror from that list. This is not good. At work, for example, we have a local mirror. We registered it with mirrormanager so that anyone coming from our IP range will get the packages from the local mirror, reducing bandwidth usage for us and giving better speeds for our users. dnf seems to pick a rather far away mirror (one that is not even in the same country as I am), downloads slowly, and then fails as if the connection was cut. dnf should respect MirrorManager's choice of mirror.
DNF behaves very much like yum with the fastestmirror plugin. Mirrors are sorted by latency. Can you determine the mirrors that DNF vs YUM are using (using eg tcpdump or tcpflow), and then ping them? IMO it'd be nice to be able to disable this and use the order supplied by user or mirromanager instead, but the latency measurement is usually a quite good metric too.
When I tested this yum was using the mirror I host, which is http://mirror.nonstop.co.il, while dnf was using http://mirror.euserv.net. If you want to do latency measurement that's okay, but it should only be done if the mirror MirrorManager suggests is not good enough. When I ping euserv, I get a latency of 99ms. when I ping nonstop, I get a latency of 18ms. Could it be that dnf caches which mirror is the "fastest" and that caching happened when nonstop was out-of-sync (every mirror gets out of sync) few hours ago (and thus wasn't on the metalink), and then when I actually ran "dnf update" it didn't re-download the metalink and thus used euserv? Anyway, MirrorManager's prioritization is good enough for most people and it should be the default. "fastestmirror" style prioritization should either be a plugin or a config switch. Some mirror has higher latency but more bandwidth, so the latency check is usually not the right thing to do.
Tomas, what do you think?
About the caching of the mirrorlist with a missing mirror. This isn't probably the cause of the problem, because: * The way DNF uses Librepo, the list of mirrors (neither metalink nor mirrorlist) is not cached -> the current list of mirrors is downloaded during each metadata update. * The same situation is during a package downloading (e.g. during the "dnf update"), the used mirrorlist (metalink or mirrorlist) is always "fresh" and current. About the caching of the fastest mirror results: * The DNF uses a cache for the results of the fastest mirror test. Max age for a record is 30 days (the default value). So, if the fastest mirror determination was affected by a network issue and this led to the situation that the mirror designated as the fastest one is not the fastest one, this information will persist for another 30 days. Elad, could you please attach your /var/cache/dnf/(architecture)/(fedora_releasever)/fastestmirror.cache file? And could you delete the file, run DNF again and check which mirror is used? The solution for similar problem could be an option that disable the fastest mirror functionality or at least an option that set max acceptable age for the cached values.
Created attachment 849466 [details] fastestmirror.cache Okay, here's the file. I still think this behaviour is wrong. I switch networks a lot. Sometimes I'm at work, sometimes I'm at home, sometimes I might be on a public wifi, and I might be abroad as well. Each of those cases will have a different network, with a different ISP, and a different connection speed to each mirror. In addition to that, as a sysadmin, I don't like this. I don't CARE how long it takes to connect to a mirror: I might be running in a cloud environment where connections to external mirrors cost more money (ie. AWS), I might have a local mirror in the office and I want all users in the office to pull from it to not waste outgoing bandwidth. MirrorManager solves all this problems. It was made to solve those problems.
Elad, we do the caching because determining the fastest mirror takes time. So we cache it now and then and then use it. Tomas and Zdenek: perhaps we should drop using fastestmirror? I have to say I also noticed it tends to be slower then just using whatever librepo would use otherwise.
It never was a huge win.. I'd tend to keep it implemented but disabled by default.
Low prio for now, but that really is what we should go after.
Thanks, from the attached file it's clear that connection time to the http://mirror.nonstop.co.il was 0.53347 and to the http://mirror.euserv.net just a 0.002616 so the Librepo chose the euserv. I see, but the MirrorManager can be wrong in some cases too and some user want the fastest mirror detection (https://bugzilla.redhat.com/show_bug.cgi?id=984529). But you are right, if someone changes connection types a lot, then it is not a much useful feature. About the metrics. I know that the connection time is not a good metric but it is a really fast and it works in the yum's fastest mirror plugin in most cases. Better approach would be downloading of dozens of megabytes from each mirror (to avoid distortion by the burst limits, etc.). But it would be slow and not appreciated by people with dial-up or mobile connection. So solution for this bug should be an option that allows to enable the detection while the detection itself should be disabled by default.
Jumping in here. I'm slowly getting really annoyed by dnf, as it most of the time picks mirrors that are quite slow or unreliable, making the whole update process with dnf a lot slower than yum from what I can see. (In reply to Zdeněk Pavlas from comment #1) > DNF behaves very much like yum with the fastestmirror plugin. Which might be the wrong thing to do. I can't recall the exact details, but I think that plugin was not installed by default in Fedora (at least not in F19 afaics) for a simple reason: relying on MirrorManager in most cases leads to the quicker mirror and thus the better user experience.
(In reply to Thorsten Leemhuis from comment #10) > Jumping in here. I'm slowly getting really annoyed by dnf, as it most of the > time picks mirrors that are quite slow or unreliable, making the whole > update process with dnf a lot slower than yum from what I can see. Fun, just after writing this, it got worse: Seems dnf not only picks a slow and unreliable mirror every time for me, but also does not switch to a different mirror if there are problems, as it currently aborts with this here: python-magic-5.14-14.fc20.noarch: Not finished - interrupted by error: Cannot download file-5.14-14.fc20.x86_64.rpm: All mirrors were tried file-libs-5.14-14.fc20.x86_64: Not finished - interrupted by error: Cannot download file-5.14-14.fc20.x86_64.rpm: All mirrors were tried It seems to me the "All mirrors were tried" part is not true; yum was perfectly able to pick a fast an reliable mirror on the first try, and dnf failed five times in a row. Are you sure the "try a different mirror if download fails" logic works at all?
Although there might a bug in librepo that skips some mirrors, I think this is almost certainly not the case here. DNF is just less noisy than Yum on mirror failures (IMO mostly a good thing).
Fixed by f5a526b. I believe the OP in bug 984529 was seeing slowdowns for some other reason than no fastestmirror.
dnf-0.4.12-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.4.12-1.fc20
Package dnf-0.4.12-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.4.12-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1270/dnf-0.4.12-1.fc20 then log in and leave karma (feedback).
dnf-0.4.12-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.