Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Colin_Higbie <CHigbie1@Higbie.name>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] Bufferbloat cure question
Date: Wed, 31 Dec 2025 22:19:24 +0000	[thread overview]
Message-ID: <BN7PPF7A8514BADF1FF90D4D0A9172A28FDF1BDA@BN7PPF7A8514BAD.namprd16.prod.outlook.com> (raw)
In-Reply-To: <176388152155.1303.12028700061090443748@gauss>

I have a question for the experts here. This is not necessarily limited to Starlink, but at Starlink's latest bandwidth capabilites, pushing past 300Mbps, this becomes relevant to Starlink. 

In my simple tests at https://www.waveform.com/tools/bufferbloat, using both Starlink and a new 1Gbps symmetric fiber connection (we're keeping Starlink for backup), I see decent but not great bufferbloat and jitter values of about 16-25ms by setting my router to a standard Adaptive QoS setting (an Asus consumer-grade router that supports 1Gbps WAN connection, RT-AX86U-Pro). When I use CAKE at lower speeds, it impressively crushes the impact under load down to about 0-1ms. But that only holds at lower speeds, meaning a bad day for Starlink where it's not pushing 300Mbps or if I set my router to limit bandwidth to about 280Mbps. On fiber, I have to limit the 1Gbps connection to 280Mbps to run CAKE and eliminate the bufferbloat.

At 300Mbps or higher, bufferbloat and jitter skyrocket to hundreds of ms, much worse than not using CAKE at all. I can see one of the 4 router CPU cores spikes to 100% at those transfer rates whenever I don't limit bandwidth to something below 280Mbps. My crude understanding is that CAKE can only run on a single CPU core (can't be multithreaded to take advantage of the other 3 cores) and becomes CPU bound at higher transfer rates. Then, when the CPU is maxed, CAKE will do more harm than good, which is exactly why bufferbloat actually increases with CAKE above 280Mbps. I understand that FQ-CoDel is similar.

All those tests are on wired connections, so these are not Wi-Fi effects.

Presumably, a faster CPU would increase the rate before CAKE becomes the bottleneck. But to my surprise, I can't find anything on the Internet that addresses solutions to bufferbloat at higher bandwidths or confirms that some modern routers have fast enough CPU to run at the full bandwidth capability of their WAN port.

I had been told that a simple Ubiquiti Gateway-Lite between the Internet and my wireless router could take on this role, that it had a sufficiently powerful CPU to handle up to about 1Gbps (or very close to that), but in my testing, first, it doesn't appear to include CAKE, and turning on FQ-CoDel, as its closest alternative, requires disabling its hardware acceleration, which dramatically harms both throughput and latency under load.

I'm willing to go up to something more expensive and powerful (like the Ubiquiti UDR7, where I like Ubiquiti for the group management of all the networking hardware from one interface with our existing Ubiquiti Wi-Fi APs, but that's not a requirement, and I don't think any of the Ubiquiti routers include CAKE), but given how hard it is to find anything on the Internet about this, it makes me suspicious that I'm chasing the wrong problem.

My chief concern is keeping jitter to a level where it will not cause any issues for VoIP or video calls. At 16-25ms, that's not bad, but it can lead to some stuttering and glitching on calls, shifting QoS to prioritize voice and video calls helps, but if I could just eliminate the bufferbloat, seems that would be a better solution.

Questions:

1. If CAKE is not viable due to CPU constraints on most modern routers as their WAN port transfer rate, then what is the recommended solution? 

2. Are there any routers that can handle CAKE at 1Gbps or 2Gbps?

3. Is there a site that provides ratings for different routers at these high bandwidths or lists MODERN 1Gbps+ routers that support CAKE up to their full bandwidth capacity? 

4. Or, at bandwidths above 300Mbps, are these 16-25ms increases considered acceptable, meaning I'm chasing perfection when I should just be happy with 16-25ms latency impact and jitter under load and accept that occasionally any Internet connection will have some problems when the connection gets crowded? 

How should I tackle finding a solution? And if I'm asking the wrong questions, please feel free to mock my ignorance in your response. :-) Let my foolishness be used educate others (and myself). 

Many thanks,
Colin

       reply	other threads:[~2025-12-31 22:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <176388152155.1303.12028700061090443748@gauss>
2025-12-31 22:19 ` Colin_Higbie [this message]
2025-12-31 23:18   ` [Starlink] Re: Bufferbloat cure question Sebastian Moeller
2026-01-01  0:13   ` David Lang
2026-01-02 18:21     ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN7PPF7A8514BADF1FF90D4D0A9172A28FDF1BDA@BN7PPF7A8514BAD.namprd16.prod.outlook.com \
    --to=chigbie1@higbie.name \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox