On Tue, Sep 25, 2012 at 05:14:58PM -0700, Adam Williamson wrote: > On Tue, 2012-09-25 at 10:34 -0600, Kevin Fenzi wrote: > > On Tue, 25 Sep 2012 13:54:34 +0200 > > Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > > > > > since some weeks "gd.tuwien.ac.at" is creeping around > > > 2-30 KB/second and i am sitting on 100 MBit WAN > > > > > > currently 68 BYTE per second on a test-vm > > > > > > since yum does no longer support switching a mirror > > > with STRG+C https://bugzilla.redhat.com/show_bug.cgi?id=860181 > > > this such mirrors should be removed or yum become a setting > > > that mirrors where a download creeps for longer than 10 seconds > > > below a user configured value taht it will be skipped > > > > Well, the thing is that it may be slow from where you are, but is fast > > for many others. ;( > > I think some of Harald's other suggestions in the mail are pretty good, > though. It does seem like yum could try harder to throw out slow > mirrors. It is a bit annoying when you're sitting on a 50Mb/sec > connection getting about 200Kb/sec from some sclerotic mirror... To be honnest the above behaviour happens extremely frequently here but with various mirrors, I'm in china and connections are not managed nicely by ISPs and server (don't tell me to switch ISP, there is only 2 available I tested both !). So the server may burst at 100KB/s and be suddenly throttled down to a few bytes per second. For fun while trying this email i just did a yum update -y libxml2 right now I'm seeing: updates/primary_db 0% [=- ] 1.3 kB/s | 605 kB 69:11 ETA Sure I'm just gonna wait one hour to see if there is an update available to my package ! The potential user base for Fedora in china is huge, but ATM I perfectly understand why no one would ever want to use it, it's very hard to update our OS unless tweaking the timing database and playing continuously with the available server list :-( Time to write the couple above sentence and now it's updates/primary_db 0% [=== ] 158 B/s | 1.1 MB 536:51 ETA you really expect to wait for the completion of the download to mark that server as unsuitable and switch to another one as indicated in https://bugzilla.redhat.com/show_bug.cgi?id=860181#c3 And yes whether it's a single download or multiple one, the time to complete yum is at least the longuest download. If you see that a download is gonna take 20mn cancel it and switch to another server if there is one available ! If you think the code is more intelligent than the user, then make sure the code behave intelligently in all situations. Heh it improved it's only 2 hours to fetch primary_db now, how great ! updates/primary_db 0% [=====- ] 471 B/s | 2.2 MB 138:40 ETA needless to say, I'm cancelling the command.... the 0% is only moderately funny BTW. [root@thinkpad ~]# rpm -q yum yum-3.4.3-29.fc17.noarch Daniel P.S.: it's the morning, i.e. the network is not loaded compared to the evening. -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
