View Full Version : Implement a bandwidth test in up2date?

18th November 2004, 12:50 PM
First of all let me say some words ;)
- I am able to modify the up2date mirrorlist for my needs - and it works
- I normaly use yum from commandline without any problems
- I am able to locate the fastest possible server because i know the bandwidth

This topic question raised a few days ago, while a client told me the following thing:

"It seems to be like murphy's law: whenever it is possible for up2date to select the SLOWEST server to download from, this server is taken! And very impressive is to download from dot-jp servers..."
I havn't realized this "feature" because i didn't use this application...

Please don't get me wrong: we all know that it is possible to modify the server-downloadlist - but that is not the goal. I know how to handle it - but me is not everyone...
And modifying the up2date files may end up in errors if the server is down, too many users are connected etc. -> not newbie-friendly ...

Especially for newbies it is hard to understand, why a download start's with 5KB/s using a 3MBit DSL connection...
Also a newbie want to use an application "as is" and don't want to modify files with root access - and maybe implement hard to find errors...

Today i've tested this "feature" - with success: up2date has taken a "horror-bandwidth-server" with 3KB/s. Testing the complete list (see /var/spool/up2date files) , i found the fastest possible server - located in US.
This "feature" is already visible when "fetching the headers" and "solving dependencies". If this processes start slowly, abort and restart up2date until it will act faster. Then you're sure the have a fast downloadserver...

From my point of view, it might be no problem for a programmer to mofidy the up2date workflow like this:

-> application start of up2date
-> Get mirrorlist (exists)
-> test on fastest server (new - maybe with minimum speed limit value given by user: e.g. 70kb/s)
-> set fastest server (new)
-> start main up2date process (exists)

This might be a newbie-friendly process - without modifying default values and will end up to a needful application...

Just an idea, just my 2 cents...

18th November 2004, 03:00 PM
I agree, that up2date and yum should get a function like mirrorselect in gentoo, that is very nice.
But here is afaik the wrong place for such requests, because we are not an official RedHat Forum. The developer mail list is the better alternative.

18th November 2004, 03:18 PM
But here is afaik the wrong place for such requests, because we are not an official RedHat Forum. The developer mail list is the better alternative.

It's not a request, it's an idea. Maybe it is useless.
It might be interesting to know, if this idea is a will of other ppl, too. Maybe other ideas will grow up and we are able to create a useful package. And with THIS created package - developed by fedora forum users - we can contact redhat programmers presenting a useful change - based on facts. Maybe already tested.

In other words: Problem -> Idea -> tested Solution.
If we throw it away during discussion, we save developer-time ;) ... And otherwise we know exactly how it should work...