Re: Comments on the fastestmirror plugin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2010-03-12 at 14:21 +0000, Fred Williams wrote:
> On 12 March 2010 14:08, Patrick O'Callaghan <pocallaghan@xxxxxxxxx>
> wrote:
>         The yum fastestmirror plugin (yum-plugin-fastestmirror) claims
>         to
>         evaluate the speed of a bunch of repo mirrors and use the
>         fastest one
>         relative to the user's location.
>         
>         However AFAIK what it *actually* does is make a test
>         connection to the
>         to the candidate mirrors and order them according to response
>         time,
>         which in many cases is dominated by network latency, which can
>         distort
>         the results. For well-connected user machines in first-world
>         countries
>         it probably doesn't matter much, and may have the beneficial
>         effect of
>         spreading the load over a wider range of mirrors, but for
>         those of us in
>         a less privileged position it can matter a lot. Ironically,
>         these are
>         the cases where such an optimization could do the most good.
>         
>         A case in point: I live in Venezuela and on several recent
>         occasions yum
>         decided that my closest repo was in Puerto Rico, which as the
>         packet
>         flies is probably true. However the b/w I got as a result was
>         around 2
>         or 3kbps.
>         
>         I tried renewing the mirror cache. No difference (ping times
>         tend not to
>         vary much).
>         
>         I then manually edited the /var/cache/yum/timedhosts.txt file
>         to bias
>         the results against the mirror yum was choosing (I made it
>         worst rather
>         than best). Oddly, it again made no difference! It seems
>         there's a
>         cunning hidden cache of these results that I don't know about.
>         Finally I
>         disabled the plugin completely and got decent b/w without it.
>         
>         Perhaps we should be considering some kind of BitTorrent
>         version of the
>         repos in which the mirrors are seeds and the users are
>         leeches, though I
>         realize that this is harder than it looks, particularly when
>         taking into
>         account the synching of the mirrors themselves.
>         
>         poc
>         
>         --
>         users mailing list
>         users@xxxxxxxxxxxxxxxxxxxxxxx
>         To unsubscribe or change subscription options:
>         https://admin.fedoraproject.org/mailman/listinfo/users
>         Guidelines:
>         http://fedoraproject.org/wiki/Mailing_list_guidelines
> 
> Perhaps not so difficult - though I've never used them myself, I
> recall that in the Debian, if not Ubuntu (Sometimes hard to tell)
> repositories are some packages that allow for bittorrent fetching of
> deb packages - perhaps if they're still relevent and working, they
> could be used as a base to create a means of implementing the same,
> maybe as a plugin for Yum or similar.
> Theoretically, I think the only main differences are the download
> protocol. HTTP/FTP or BitTorrent. Once downloaded the package can
> still be used in the same way, there's no difference there.
> The main downside I see to it is that those users on an ISP which
> throttles BitTorrent will suffer, and have to go back to standard
> downloads, but if both are provided, then no issue. Or at least very
> little.
> Just my 2p. Or 2c, depending on your currency.

Interesting. I'll see what I can can find on BT use in the Debian/Ubuntu
world.

poc

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux