Description Jeff McAffer 2008-06-03 21:06:29 EDT

there are some pathalogical situations where a large set of mirrors in the list are bad.  For example, when the mirroring process has not yet completed or the repo in question just is not being mirrored but the server says it is.  To a certain extent this is just bad data management but the sceanrios seem real enough (indeed they are part of our normal development process).

Currently the mirror selection algorithm has a logrithmically decreasing chance of choosing from a sorted list of mirrors.   This is good but there still seem to be a large number of cases where all download threads are pinging the same server.  In the initial case this is a problem if that mirror is somehow bad.  For example today there was a mirror that just did not respond and we were not timing out.  In that situation it happened that all 4 download threads were working on the same mirror so the insatll process stopped.

in the initial case when we have no mirror quality information it seems prudent to not put all our eggs in one basket and to have at least one or two of the threads trying other servers.

Similarly, while a server might give good bandwidth for a particular download, doing 4 concurrent downloads from that server may not be the best answer.  Especially if the next server in the list has a similar bandwidth rating. 

So the general direction here is giving the mirror selector better context so it can better ensure consistent performance.