>By comparison, Viasat, 630 ms, and HughesNet, 724 ms, are almost unusable for these purposes.

They're saying it's close compared to starlink's competitors which aren't even the same order of magnitude. In context I think it's a fair assessment.

They are also thousands of miles further out. I believe hugesnet services almost the entire globe with just 3 satellites.

Yea a buddy tried out HughesNet and the latency was 1~1.5 seconds. Loading anything was death.

We’re talking about humans here. A human might notice 45ms in a shooter, but not when just surfing the web. Compare that with 500-1000ms latency from older forms of satellite service, or 250ms from old dial–up service.

>A human might notice 45ms in a shooter, but not when just surfing the web.

You are forgetting round-trip request latency, handshakes, and dependent resources (don't know what to fetch until receiving the first thing, then the second level of things, etc., this can stack to multiple seconds).

High latency is very bad for browsing. The main things it is fine for are streaming audio/video (non-interactive), large downloads, and backing up/uploading files.

You’re not wrong, but not relevant either. If your RTT to the server is 15ms, then connecting to that server with TLS1.2 will take 4×15ms = 60ms. On Starlink that will currently take 4×45ms = 180ms. Yes, 180ms is three times 60ms, but to a human that is irrelevant. Humans can’t detect time intervals of less than 100ms, and can only barely detect intervals less than 200ms. In a direct comparison between the two, humans will rate the 60ms connection as instantaneous and the slower 180ms connection as nearly instantaneous. This makes them “close” as the article described, especially when compared to old–school satellite links where the RTT can be insane.

And the handshake time doesn’t compound; there is no need to open a new connection to the server for every resource needed by a webpage. The web browser just keeps reusing the same connection until it runs out of resources to fetch from the server.

> And the handshake time doesn’t compound; there is no need to open a new connection to the server for every resource needed by a webpage. The web browser just keeps reusing the same connection until it runs out of resources to fetch from the server.

Third party analytics and other resources often means it compounds even for handshaking, but dependent resources can compound too even on the same server even if they don't each need a handshake.

It's close compared to latencies over traditional sattelite internet where a ping of over 400ms is not uncommon. The article quotes a latency if over 600 or 700ms. At least 45 is in the same order of magnitude of common broadband.

45ms reminds me more of 3G than of any normal internet connection, but that's still much more useful than the latencies the sattelite competition offers.

Who is getting 14ms on their fixed broadband. Last 3 places I can remember, I had cable and fiber to the home. My two cable connections would get 25-35ms at best. The fiber to the home wasn't much different but did go sub 20ms on occasion.

AT&T FTTH in Texas. Its 2-3ms from my home to Google's CDNs. 2-3ms to Cloudfront. 4ms to akamai. Its 3ms to my friend's house, 1ms to my work's office. Its 2ms to my colo in town.

40ms is me essentially connecting halfway across the country. A Digital Ocean droplet in SF or NY is ~40ms.

How are you measuring this? Because I just ran a ping from my colo server in a datacenter and am seeing 11-12 ms when I ping google CDN.

All of this was measured on my residential FTTH internet from a wired desktop just using the Windows ping utility.

11-12ms to a Google CDN from your colo? That's insane to me. Pinging from my colo to Google using the ping utility from iputils for 50 packets gives an average ping of 1.6ms. Akamai pings at 2.1ms.

Ok, so I ran a ping again from my data center server. And for CDN.google.com, I get average of less than 0.2ms ping. But, when pinging www.gstatic.com, that is when I get more like 7-10ms.

I'm not sure what the difference is between the two.

Depends on where you live and where you measure to. Generally, it's fair to measure to the first IP hop, if you live far from any major internet exchange, that's going to add to your latency regardless.

I've seen fast-mode DSL around 7ms, interleaved DSL around 20 ms, cable usually 5-10 ms, but highly variable. ATT GPON was 5 ms which I thought was pretty high, although fiber should really be sub 1 ms.

I've seen LTE between 10 and 60 ms (or worse, when it's congested), older technologies are usually quite a bit more.

How are you measuring? Everyone is saying they get such low latency, I just ran a ping to 8.8.8.8 and get the following on my colo server in a Las Vegas data center:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.4 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=10.6 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=10.9 ms

I get about the same from my home cable internet connection.

I am on Google Fiber and I get < 10 ms to anything served out of a CDN or to servers in my own state. If I ping google, reddit, amazon, etc they are all about 8 ms.

Xfinity, Silicon Valley:

  --8<--

$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=15.8 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=14.8 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 14.774/15.162/15.828/0.473 ms

-->8--

Our rural fixed wireless has 5-10ms jitter, but 14ms (up to 25ish ms cause jitter) is easily observed when pinging CloudFlare via the KCIX exchange (where our ISP sends most of it's traffic).

Just ran a speedtest on my phone; I get 19ms on a Farmer's Telecom fiber. 60-70ms on the work VPN.

The last time I had >20ms RTT "Fast Path ADSL" was still a thing.