Ok. I'm trying to find out what causes occasional high bufferbloat and thought maybe the Fritzbox causing it. I made a few test rounds and it doesn't look good. The BB is getting quite high again, up to 83ms on DL and 21ms on UL.
Are the following options in the SQM settings correct:
Interface name: eth0
Squash DSCP on inbound packets (ingress): Do not squash
Ignore DSCP on ingress: Ignore
(ECN) status on inbound packets (ingress): ECN (Default)
(ECN) status on outbound packets (egress): NOECN (Default)
Which link layer to account for: Ethernet with overhead
Yeah, it does. I looked it up and did some cursory research a few weeks ago. Well, no harm in trying bridge mode first.
@bingbangbong I use a DOCSIS 3.0 Motorola MB 7621 modem with 400/20 ISP service and only occasionally can I run a test like Waveform's and get BB at the 95th percentile below 40ms. Over the coarse of the test a spike or three in the low hundreds range that "break" the tails of the probability distribution is not uncommon. But BB overall is still vastly improved with CAKE.
A spike of 463ms is pretty bad, but the preceding paragraph is a long way of saying it is hard to appreciate how bad your DL 14-464 ms range is, not knowing the data distribution in that range. And also a long way of saying a new modem without a Puma chipset may very well help, but it may not achieve perfection.
Think about spending some more time with the Fritzbox in bridge mode before looking for a new modem, and paying as much attention to how your connection works as the numbers coming out off a buffer bloat test. If the connection works better and your gaming experience is acceptable now, who cares what the BB test numbers say, and maybe don't waste money on a new modem? If you're getting a lot of spikes in the hundreds of ms that hurt gaming, then perhaps it's time to buy a new omdem (or even better, a less expensive used one) without an Intel Puma chipset.
Other thoughts I had reading through your experience:
8-40ms on upload is pretty good from my experience with DOCSIS 3.0 cable ISP. No doubt others regularly expect and get better, but still, max below 40 ms is pretty good.
If you are running the BB test over WiFI, it could be your WiFi adding to the bufferbloat?
Finally, if any of my opinions contradict moeller0, take mine with a grain of salt - he's forgotten more than I know about BB.
+1, however a browser is not a perfect measurement environment and the results of especially the waveform test depend on the browser as well. Case in point, I see more outlyers when using safari compared to firefox. So my take is that the waveform test is pretty useful, but one needs to expect some amount of higher latency samples compared to better controlled tests like netperf/iper2/iperf3, without that being diagnostic for a misconfigured sqm instance....
To be explict, the waveform test is great and useful, but partially measures delays introduced by one' browser and such delays can not be 'fixed' by sqm on one's router.
I played a few game rounds yesterday and the experience was partially very good and partially very poor. When things were working fine, every bullet hit and I didn't lag at all... It was a whole new experience since forever... then suddenly I shot blanks and I was like second or two behind the "real time".
This is a difficult situation because I can't be sure whether or not the FB is causing it. I just in case reseted it to the factory settings and set up again. I thought I also make test the firewall disabled but unformatunatelly there is no option to disable it. Seems the only option is to buy a new modem (without the Intel Puma processor).
@moeller0 Only my TV is using wifi for streaming. The PC is connected with eth cables. I anyway I ran BB tests with wifi on and off, but there was no difference in the results.
Anyways, thanks a lot guys for your help. I have to accept the situation what it is now and will continue then when I have got a new modem. Meanwhile I'm going to focus on another issue in another forum... No sound in games when using AMD HD Audio... Life isn't easy
So under continuous load cake/fq_codel by default accept a 5 ms standing queue (its target control parameter*), so under load your RTT will b increased by at least 5ms per load direction, empirically (since cake will tolerate 5ms and only intervene when 5 is exceeded the actual standing queue with normal traffic (that is not only very long running flows) is often closer to 2*target or 10ms. Judged from that the data up to 200/15 looks OKish, 285/19 however seems a bit too high. That can be your link, CPU overload on your router and/or too high demands on your browser or any combination of these factors...
*) by default cake will start dropping/ecn marking if for the duration of interval (default 100ms) the minimum sojourn time (essentially a packets experienced queueing delay inside the AQM) was above the target value. That adds an additional slack factor to the equation which will result in the actual queuing delay exceeding target by a bit.
Thanks for this (tries to look like understanding everything)
So this means that my speed is now max 200/15 mbits if I want to avoid bufferbloat rising too high. Does this also mean that if I upgrade my connection to 600/30 mbits, then speeds above 200/15 mbits will cause a higher bufferbloat, which means the upgrade will be useless?
By the way, how do the traditional Windows network settings work with OpenWRT? Is there anything you shouldn't do? For example, I've tried to reduce latency with CMD and PowerShell commands, e.g. "netsh int tcp set global rsc=disabled" and "netsh int tcp disable heuristics" and the like. Then I've made so-called game adjustments to the NIC driver... like disabled 'Interrupt Moderation', and 'Offload' options and so on. Sometimes I also disable 'Receive Window Autotuning', which reduced the buffer bloat a bit, but caused other problems at the same time. Some network adjustments for gaming seem to be placebo and some just might increase latency and cause other problems. There's still some learning to be done here, how to avoid messing up the system's functionality in the hope of better results.
If your router can't handle those speeds with SQM (which requires a lot of CPU power) then upgrading won't help. If you have enough CPU power, then you should be able to go much higher if you upgrade.
That depends on what is the cause of the increased delay. If it is overload of your router's CPUs then increasing the link rate and shaper rate will make the situation worse. If it is your ISP then it depends on how the cable segment's capacity is shared between all users in that segment.... If it is your modem then all bets are off (I have no experience with bad docsis modems so can not reasonabky formulate what to expect).
I have the same impression, but I do not game much at all and when I do then mostly non-networked games on Ubuntu...
I do have some sympathy for gamers though as I share their appreciation for low latency and low jitter, and for their can do spirit when trying even the most obscure placebos....
For reference, here is my R4S shaping 380/19 Mbps down/up with CAKE. The screen shot is in the middle of the test period shaping 380 Mbps. Today anyway, Ookla Speedtest reports latency of 20/18/17 ms for unloaded/down/up.
The R4S A53 CPU cores 0-3 run up to 1.5 GHz and the A72 cores 4-5 up to 2.0 GHz. Schedutil has only run the clocks up to 1.0/0.8 GHz and there is still a fair amount of CPU head room. I have irqbalance enabled with its defaults and packet steering turned on.
Correction - max clock on the A72 core is 1.8 GHz.
It may be a gross estimate of R4S capability, but assuming everything is proportional and CAKE is running on core 5 at 65.1% load, then that A72 core might shape up to 380 Mbps * 1.8 GHz/0.82 GHz / 65.1% Mbps? This works out to being able to shape ~1.3 Gbps with CAKE. Seems a bit high, but there is more than one report of the R4S being able to shape Gbps, so....
The same math, assuming CAKE is running on core 1, works out to 937 Mbps, which is clearly impossible for a slow A53 core, so I'm going to rule that assumption right out.
The A72 is a pretty nice CPU from ARM performance series, four of these power the raspberry 4B which is also known to be able to traffic-shape at @1Gbs. But in theory not knowing what else runs on a router even the fastest CPU can become overloaded, in practice I agree that it probably is not the cause of the observed issue.
I have 4 cores running at ~1.3Mhz under powersave. I'm only using less than 11% on one core for cake @ 200/20 after tweaks. You have plenty of headroom to make adjustments to bring that usage way down.
(I have no experience with bad docsis modems so can not reasonabky formulate what to expect).