[...]
[...]
The IPv4 subnet of
104.16.0.0/12, which includes NiceHash's IPv4 address of
104.17.254.46 and Mining Rig Rentals's IPv4 address of
104.26.0.61,
belongs to Cloudflare. The IPv6 subnet of
2606:4700::/32, which includes NiceHash's IPv6 address of
2606:4700::6811:ff2e and Mining Rig Rentals's IPv6 address of
2606:4700:20::681a:3d,
also belongs to Cloudflare. Therefore, the most plausible reason for why the measured latency from the pool to those hosts were so remarkably low isn't that NiceHash's and Mining Rig Rentals's servers are in the same datacenter as the pool, but that the ICMP echo request packets sent by the pool to those addresses were directed to Cloudflare's CDN instead of the upstream hosts. The latency measurements by -ck are therefore meaningless, as -ck measured the latency to Cloudflare's CDN, which most likely has a network of nodes in the same datacenter as the pool, instead of NiceHash's and Mining Rig Rental's upstream hosts.
If your network supports IPv6, then I recommend using IPv6 instead of IPv4. Routing and packet processing are more efficient with IPv6, which therefore theoretically results in better overall network performance. And since both NiceHash and Mining Rig Rentals also rely on Cloudflare's DNS infrastructure, you would do well to set
Cloudflare's public DNS resolver as your network's DNS resolver. It may help to shave a few milliseconds when resolving NiceHash's and Mining Rig Rental's domain names. For the more adventurous folks, you may also want to consider running OpenWrt on your network routers and then running
Stubby for OpenWrt with Cloudflare's public DNS resolver as its upstream resolver. If you do run Stubby for OpenWrt, then I recommend forcing its use of TLS 1.3 and disabling Stubby's round-robin scheduling of upstream resolvers. And while you're at it, you may also want to consider
running luci-app-sqm to help mitigate bufferbloat, which in turn helps to improve network performance under load.
.