On Fri, Apr 21, 2006 at 07:34:41AM +0000, Ola Thoresen wrote: > 2006-04-21 Callum Lerwick <seg@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
