Thx rich for weighing in. I agree with your suggestion, in that it seems likely your router is struggling to keep up. (I gave up and switched to x86 openwrt boxes).
BUT: If there was some way to address the folk saying "You don´t have bufferbloat with normal use" definitively once and for all?
NORMAL USE has TCP "SLOW START" in it. Please read about that in wikipedia or see the explanation here:
*Every connection that lasts long enough* will hit the buffer until it runs out of space and gets a drop, then the rate will be cut by 1/3 (tcp cubic) and then start to grow again (¨Congestion avoidance¨), until it buffers and gets another drop. So a single tcp connection that lasts long enough will induce latency on the link, and on slow start, especially, jitter.
Thereś a key caveat here - "lasts long enough", and here is where people draw the conclusion - most web traffic has a bunch of short flows that in sum rarely exceed 20Mbits/sec at any given instant. At a 400Mbit level it will take seconds of a big download (say, a game) to finally hit this behavior. Or, one or more of the other devices on your network might do you in in this way. Microbursts exist, too...
Secondly, the uplink here is amazing (0?), and I am not sure why it is that good!
Thirdly, 100ms is really quite decent for downlink bufferbloat, and I might even agree with the commentors that it is unlikely to be much of a problem, except that I do not trust this test to be accurate at this speed! In a single queued system, 30ms would be preferred, or with a FQ´d system 0 is feasible. I keep hoping more will ask their ISPs to install something like LibreQos.io´s CAKE implementation on their downstream shapers to achieve that, (confession, I am part of that project, and the basic software is free, and a cheap Xeon can shape 10k subscribers).
Yes, you can also shape on your own the ingress but it does require heftier CPE, and is nowhere near as effective as the ISP doing it.
In the many years since the bufferbloat effort started, we have had many advances across the board - device updates, for example, tend to use a much gentler protocol than cubic, netflix does better pacing, as does all of linux, but for the best latency and jitter, sqm at the ISP -> down and cake -> ISP up remains the penultimate never worry about bloat/jitter/latency ever again thing.