Please don't confuse latency (ping) for bandwidth

[Joshua Root]

On 2020-7-10 23:49 , Christopher Chavez wrote:
> In https://trac.macports.org/ticket/60509 it is explained that MacPorts
> uses pings to find nearby servers, and it is claimed nearby servers will
> likely be the fastest.
> 
> I'm not a network engineer, but can say this claim is a myth. The
> purpose of ping is to measure latency, not bandwidth. Yes, sufficiently
> low bandwidth will increase ping time. But measuring bandwidth directly
> involves something else besides pings, such as transferring a
> sufficiently large amount of data and timing how long it takes to do so.
> 
> I'm fine with MacPorts claiming to use pings to find nearby servers, but
> it should not make or repeat the claim that doing so will do a good job
> of finding the fastest server.
> 
> 
> Anecdote: for some time, even though I typically use a 60Mbps+ Internet
> connection (Spectrum) and live ~100km (>30ms) away from the MacPorts
> servers in Austin, TX, I've opted to not use the UT Austin servers
> (~1MiBps) because other MacPorts servers such as ykf.ca.*.macports.org
> (>60ms away) are far faster (~6MiBps, or about as fast as my connection
> can go). I've also configured MacPorts to prefer downloading distfiles
> from often-faster CDNs for projects on SourceForge, etc., even though
> they may be several times farther away than my regional MacPorts
> distfile mirror, and some of which aren't pingable. (I wonder if
> MacPorts should even be in the business of defeating the purpose of
> these CDNs, but I would expect to be told MacPorts has learned to
> distrust upstream projects with hosting distfiles properly.)

You are correct that ping is no substitute for an actual measurement of
throughput. However, there is in general an inverse correlation between
ping time and achievable throughput. This is partly because high latency
tends to mean there's an international link involved, and those tend to
have comparatively limited bandwidth, and partly because the increasing
bandwidth-delay product and greater chance of packet loss can result in
TCP window collapse.

Certainly when there are several candidates which all have low latency,
we don't have a good way of deciding between them.

If you have ideas for how MacPorts could efficiently do a better job of
estimating the likely throughput of hosts, patches are very welcome.

- Josh