Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Introduce entropy for fastestmirror option
Traditionally the fastestmirror option has relied on taking the provided mirrorlist from the repo CDN and measured the latency to each mirror by timing the libCurl socket open time. This has resulted in several undesirable properties for the fastestmirror option: 1. Socket open latency is not always a good proxy for download bandwidth performance, so if the nearest mirror to a user happens to be particularly slow, they will always experience a very slow download despite having fastestmirror enabled. 2. Mirror operators don't appreciate fastestmirror being used by high density deployments (i.e. data centers) where thousands to millions of hosts with fastestmirror enabled all dogpile the single lowest latency mirror despite there being several mirrors within almost as close proximity to the site This change introduces entropy into the mirror selection process by taking all mirrors with latency measurements less than twice that of the nearest mirror and shuffling those mirrors evenly, then simply appending all other mirrors to the end of the list in strict latency order.
- Loading branch information