Starlink cuts P99 Latency by 60% [pdf] | Hacker News Reader

Starlink cuts P99 Latency by 60% [pdf]

api.starlink.com

27 pointsdtaht16 comments

When I got mine a year or so ago I was frequently getting speed tests like 17mbps down/5up, which was still much better than I had before. But just now I got 135/25, and while that's unusually fast, I'm consistently seeing >100mbps download rates. But the download latency this time was 156ms, 7x their 20ms target. That's the usual and I haven't seen many lower measurements.

Have you made sure the app says no obstructions?

Yep, and the dish is on a high point, the ridge of a house on the crest of a mesa with low horizons all around, that attracts an unfortunate number of lightning strikes.

one of my sadnesses is so few tests, except those designed by the bufferbloat project, test up + down + latency at the same time.

I like this new one: https://github.com/Zoxc/crusader/releases/tag/v0.0.10-testin.... My favorite remains the rrul test out of the flent.org suite.

Most web speed tests have nearly no predictive power for testing videoconferencing quality, although I am delighted speed test.net cloudflare and others have added a "responsiveness" metric that too few see... https://blog.cerowrt.org/post/speedtests/

Under 65ms is pretty darn good considering everything that's happening, the distances involved, and all the hops. That's good enough for most people's gaming needs.

>With active queue management enabled, when one person on your WiFi is downloading a big file, and another is playing a game, the game latency will not be affected by the download.

How is this implemented? Is it just prioritizing devices/connections that are not responsible for much traffic?

It's about letting the TCP implementations on the end-points know early that the capacity of the link has been reached; so that they adjust their bandwidth usage before a long queue (which would cause latency) accumulates on the router before the bottleneck link. Active queue management can achieve this with "explicit congestion notification" (ECN, a bit in the IP header) if supported by the endpoints; or alternatively by probabilistically dropping some packets early.

https://en.wikipedia.org/wiki/Active_queue_management

Usually games use UDP, though I guess if the TCP links all get notified of congestion that could effectively ensure there is enough bandwidth available for all the UDP traffic.

most games run at 64Kbits/sec or 120Kbits and FQ helps those "mice" flows a lot, by giving them their own lane.

If also, the greedy protocols like TCP or QUIC back off on filling up buffers (via an AQM) before a gamer would notice (20ms of jitter/buffering is about right, 60ms is teetering on wrong) gamers and downloaders can co-exist happily on the same link.

Cisco used to use WRED [0], basically dropping tcp packets in order to manage the bandwidth.

0: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conavd...

WRED is so obsolete...

https://en.wikipedia.org/wiki/CoDel

Well yes, that’s why i said used to. I last studied networking in the 90s :)

It is fq_codel on the wifi: https://en.wikipedia.org/wiki/CoDel

Thank you for the steer to that article, it has some errors.

ECN is not in use at starlink (yet), so far as I can tell. The AQM in place just uses conventional - and timely - packet drop, which is the principal signal for congestion control across the internet. (so I would say " alternatively" in the Wikipedia article about ECN, and drop principally)

To this day, so many people (including the early engineers at starlink), do not get that dropping packets is how we manage latency across it for greedy flows. I have given so many talks about how this works - lose 2 minutes of your life to this, please: https://www.youtube.com/watch?v=TWViGcBlnm0&t=995s

Starlink folk now deeply get that buffering for 100s of Ms is counter productive, and have put in play many "bufferbloat" mitigations over the past year, focusing on P99 metrics in particular.

...

More importantly than AQM, their stuff does "flow isolation" and "Fair queuing" so that fat flows interfere with lighter weight flows less. https://en.wikipedia.org/wiki/Fair_queuing

The starlink wifi now does fq_codel in particular, which combines fair (flow) queuing with the codel AQM. While I do not have any benchmarks of their implementation it should show up on tests where two or more stations are trying to "do stuff" at the same time.

...

There has been a lot of hype about ECN lately (because it does not require dropping packets) but it needs to be enabled at the endpoints, and at the congested routers in-between running an AQM algorithm that also has it turned on. I do keep hoping more enable it on their OSes (apple has it on for some sites, Apple Quic does now), and more routers enable it also.

Stunningly widely supported is RFC3168 ECN across 68% or so of all websites, but few clients turn it on. Here's how you can try it:

https://www.bufferbloat.net/projects/cerowrt/wiki/Enable_ECN...

If you have a supported router leveraging SQM ( on any tech, fiber, docsis, what have you) : https://openwrt.org/docs/guide-user/network/traffic-shaping/...

I note that ECN has some major drawbacks vs a vs drop - a bad guy can abuse it, in particular, which is in part why it is not on by default. If

if?

You dropped a thought

lastly, it is not just TCP that AQMs can control, but any TCP-friendly congestion control - Quic - which is udp based - plays by those rules. Most of our videoconferencing applications in their bandwidth seeking phase, also.

QUIC's original congestion controller was based on Reno. Other versions use BBR or Cubic congestion controls:

https://datatracker.ietf.org/doc/html/rfc9002

Reply on news.ycombinator.com