Fedora Bounties (seeking ideas)

[Ola Thoresen]

2006-04-21 Callum Lerwick <seg at haxxed.com> wrote
> On Thu, 2006-04-20 at 20:09 -0400, Paul W. Frields wrote:
>> I did this by taking the old FC4 ".us.east" lists and (after
>> confirmation of the repos) including them on my system.  I wasn't sure
>> that was the accepted usage, but now it seems so.  I know there are
>> probably myriad ways to accomplish this with a more user-friendly bent,
>> but would it make sense for there to be a tool that asked the user to
>> select a geographic region, and populated a local mirror list
>> appropriately, using a remotely gathered list that included lat/long
>> data?  Does such a thing exist already and I'm just clueless?
>
> I'm thinking of hacking yum-fastestmirror to rank based on number of
> hops to the mirror, this would get you the closest mirrors "as the
> packet flies", which is probably better than geographical proximity.
>
> Though it would still be nice to track actual transfer rates from each
> mirror. I don't know if that can be hacked on in a plugin. I really need
> to learn some python...
>

As far as I rememeber, the fastesmirror-plugin downloads a small file(?)
the first time it sees a mirror and determines the time this takes, and
then sorts the list according to this timing.

The main problem with it as I see it is that it does not seem to ever
update the timing of a mirror after it is first added.  I think the
easiest would probably be to make a small addition to the plugin, so it
will either

a) Update the timings of one or more "random" mirrors every time it is
run, so you are sure to pick it up if a mirror had temporarily problems
the first time it was timed, or if a mirror is upgraded with better
connectivity and so on.

or

b) Use the acutal transfers from a mirror to update its timings.
- So if a mirror is considered the "fastest" by the first timing, yum
  will us this mirror on the next run. But this run will also be a
  new timing of said mirror, so that if it was just "lucky"
  being the fastest the first time, and it turns out it is really slow
  for actual use, it will be moved down the list for next run.
This requires a change in "timedhost.txts" so it no longer logs the
number of seconds the download used, but rather use some kind of "speed"
(IE. kbps) that is calculated from the transfers.

Any of these solutions will probably make fastestmirror a lot better
when it comes to actually determining the fastest mirror.


Rgds.

Ola Thoresen