Bug 1043177

Hi!

When running yum in a situation where there's a lot of data churn on the mirrors, I often encounter cases where all mirrors don't have the same set of metadata stuff available to download, and it causes yum download errors. 

I tried to make yum specifically use the public mirror from the metalink that has the highest priority. I know this mirror is up to date, I maintain it :) So there's no reason for my boxes not to use it... I verified that the "failover" option is correctly set to "priority".

But while running a "yum update", I noticed that yum still tried to download metadata urls from other mirrors, that were not uptodate, which caused download errors. I searched again, and found that urlgrabber launches by default up to five connections in parallel. This value can be controlled by the max_connections option in yum.conf, so I decreased this value to "1".

And again, I noticed that yum still tried to use other mirrors. I found that urlgrabber also uses internally a "default_speed" value to discard the current mirror if the estimated download speed is below the "default_speed". This mirror shuffling occurs _even_ if the current download did succeed. This default_speed is relatively high (1e6 # 1Mbit, line 1002 in grabber.py).

According to my speed tests, I think this value expresses bytes rather than bits, so the default_speed is rather closer to 10Mbit instead. With a download speed of 380kB/s (kBytes) displayed by the yum progress bar, the estimated speed for my mirror around line 2291 of grabber.py is 510454, which is below the default_speed, and causes another mirror to be selected.

Also, when the box is on a slow network, below this default_speed, no mirror can achieve the download speed expected by urlgrabber, and that certainly may cause many "mirror rotations", useless in this case.

I suggest to fix the default_speed value in urlgrabber (125e4 for 1Mbit), and ideally, this value could be added as an option in the yum config file (for people on permanently slow networks) ?