[Yum-devel] Fastest mirror selection plugin

Luke Macken lmacken at redhat.com
Sun Aug 14 00:40:10 UTC 2005

On Sat, Aug 13, 2005 at 01:56:09PM -0700, Michael Stenner wrote:
| I really like this idea, and it's clear that it's simple to implement.
| However, I'm inclined to implement it with select rather than threads.
| Threads aren't bad in a simple case like this, but select is simpler
| still.  I'm generally inclined to go that route for network stuff.
| Using select also has one other advantage: you currently wait the
| timeout for all threads to return and then pick the fastest (well,
| sort, really).  You could also simply stop waiting after you get the
| first N responses.  So, for example, if your first mirror responds
| after 0.2 seconds, you can just stop waiting for the rest.  Sure, you
| can do that in threads, too, but it's harder.

The current implementaiton waits for all of the threads to
finish/timeout as well; but picking the single fastest mirror is
probably not a very good idea.

Correct me if I'm wrong, but assuming the worst case scenerio where every
mirror is expected to timeout, my algorithm takes a maximum of the
socket timeout (2-3 seconds usually) where as a select() implementation
would take (socket_timeout * num_mirrors).  This a pretty big
performance hit to take just for a 'simpler' implementation, if my
assumptions are correct.

| I'm not unconvincable here.  I just wanted throw the idea out and
| throw it early so we could talk before you spend a lot of time on it.

I totally agree, I think we should hash through as many ideas as
possible before we put all of our efforts towards one.  I based my
original implementation on speed over accuracy, since it only judges the
mirrors 'speed' by the time it takes to connect, and not by it's
actual throughput.


More information about the Yum-devel mailing list