Yum broken behaviour on slow server [was: request: remove "gd.tuwien.ac.at" from mirror-lists]

[Daniel Veillard]

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 at thelounge.net> 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 at 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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/