Fedora Bounties (seeking ideas)

[Luke Macken]

On Fri, Apr 21, 2006 at 07:34:41AM +0000, Ola Thoresen wrote:
> 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.

Nope, it only times how long it takes to open a socket with the mirror.

> 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

There is a 'maxhostfileage' option which will refresh your mirrorlist
after n days.

> 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.

Definitely sounds feasable.  Send patches ;)


luke