Re: [PATCH setup 0/3] Speed estimation for mirror list sites

Jon Turney via Cygwin-apps <[email protected]> Thu, 2 Apr 2026 21:01:07 +0100
Newsgroups gmane.os.cygwin.applications
Message-ID <[email protected]>
On 20/02/2026 19:02, Brian Inglis via Cygwin-apps wrote:
> On 2026-02-20 07:47, Jon Turney via Cygwin-apps wrote:
>> Add a simple speed estimation for mirror list sites.
>>
>> Use it when no previous (from settings) or explicit (via --site options)
>> site selection is made, to give a speed-sorted site selection dialog.
>> In that case, in unattended mode, also automatically select the 'fastest'
>> mirror site.
>>
>> Jon Turney (3):
>>    Rename site_list -> selected_site_list for clarity
>>    Drop maintaining SiteList in order
>>    Add speed estimation for mirror list sites
>>
>>   Makefile.am           |   2 +
>>   SiteSetting.cc        |  30 +++-----
>>   SiteSetting.h         |  16 ++---
>>   SiteSpeedEstimator.cc | 158 ++++++++++++++++++++++++++++++++++++++++++
>>   SiteSpeedEstimator.h  |  44 ++++++++++++
>>   gui/SitePage.cc       |  60 ++++++++++++----
>>   ini.cc                |   4 +-
>>   nio-ie5.cc            |   2 +-
>>   8 files changed, 270 insertions(+), 46 deletions(-)
>>   create mode 100644 SiteSpeedEstimator.cc
>>   create mode 100644 SiteSpeedEstimator.h
> 
> For ping and mirror test scripts, I use a timeout of 100ms, as otherwise 
> it takes *minutes* to go thru all "close" North American mirrors in 
> Canada/US:

Using ping seems like a bad idea.

* hosts don't have to reply and networks can drop them
* the i/o speed at the far-end might well be the limiting factor
* might not even possible for unprivileged users?

> 200ms is enough to reach mirrors on the ~opposite side of the globe;
> 55S 115E would be Southern Ocean S of AU and W of NZ, so used those 
> sites as proxies for worst case network route timing!
> 
> Buffer of 100KB is barely larger than default 64KB, so could just 
> allocate that size buffer, fill it, and time it in a single operation.
> But on GB/s home broadband that only takes 95us, so setup overhead might 
> dominate, maybe should bump the buffer and sample by an order of 
> magnitude to 1MB to get close to 1ms time.

Well, there are indeed tradeoffs here, but I'd lean towards not taking 
too long on the slowest possible link. If we don't give an accurate 
answer because everything is fast, that's not really a major problem.