State of the Bloat

Just did a reference measurement on my 100/40Mbps vdsl2 line from Deutsche Telekom with a stock FritzBox7520 (FW7.13) and was pleased to find the added Latency under Load on Ingress is now at ~35ms with ten flows from a close source.
iirc it was around 100ms in 2018 and around 250ms the years before.

Latency und Load on egress was only ever a Problem with the Speedport units.

1 Like

Ingress latency seems quite good on a 50/10 VDSL2 line from Deutsche Telekom I tested recently.

Egress however was well above 1000 ms on the connected stock FritzBox 7590 (FW 7.12 or 7.13, can't remember) running a apeedtest.

I have a Fritz!Box 7490 sitting in front of my OpenWrt router and without any SQM on my router, and latency seems already pretty good. I suppose AVM has made some bufferbloat improvements themselves.

1 Like

I believe that AVM actually automatically does some traffic shaping which might help your test case.

That looks about similar to what I see, base RTT of around 30ms with cyclic ramp up to ~75ms, but I need to repeat these measurements over ethernet to rule out that ath9k's airtime fairness saves my bacon here...

They are rumored to interpret the goodput estimates that Telekom sends as part of the PPPoE authentication process to configure their internal traffic shaping. Due to lack of AVM hardware I could never verify that though.

on the subtle hidden support page

activating the ingress shaping (and setting a limit) actually does nothing as far as i can tell...
but the "auto-mode" smells like cake :wink:

yea, the device has the line stats available so i guess it runs some sort of fq with a shaper for the egress.


Ah, glad I hedged by admitting I have no FB device to confirm the rumors :wink:

I am almost sure it is not, AVM tries to do their own thing and to get away from the GPL as much as possible as far as I can tell (and don't get me wrong, that might make a ton of business sense for them, so I am not blaming them, even though personally I prefer stuff out in the open).

I always wanted to get the output of
tc -s qdsc and tc -d qdisc from a running FBB with activared shapers, but I believe the one time someone tried to get this it turned up empty (not sure why, potentially because AVM tries to do these things outside of the kernel.)

just noticed that if the router is flooded (test-bandwidth > egress-bw) with udp traffic, it goes belly up (1s latency and massive droprate).
so while there has been significant improvement of the "default state" of the ingress/isp side (at germanys incumbent dsl isp, dtag), the default cpe situation still leaves a lot to be desired.

That is a hash DOS-type test though, that sqm-scripts will also not deal with too gracefully...