Under load, a 200-user network felt broken in a way no speed test could explain. Bandwidth was fine. Latency under load was catastrophic — video calls stuttered the moment anyone started a large upload. The enemy was bufferbloat, and the weapon was supposed to be FQ-CoDel.

I got it wrong first, got it right second, and then found something better.

The measurement

Idle ping to the gateway was 2 ms. Saturate the uplink and it climbed past 600 ms — packets sitting in oversized driver buffers waiting their turn. That delay, not throughput, is what users feel as "the internet is slow."

# flood the uplink, watch the gateway RTT
ping -i 0.2 192.168.1.1 &
iperf3 -c uplink-test -t 30 -P 8

# idle:    2 ms
# loaded:  640 ms   <-- bufferbloat

Attempt 1 — wrong

I enabled FQ-CoDel on the WAN interface and set the bandwidth limit to the ISP's advertised rate. It barely helped. Shaping at the line rate leaves the real queue in the modem, where CoDel can't see it.

Attempt 2 — right

Two changes fixed it: shape to ~92% of measured (not advertised) throughput so the queue forms inside pfSense, and apply FQ-CoDel on both the upload and download limiters.

1. Measure actual sustained up/down with the modem in bridge mode
2. Create two limiters at ~92% of those numbers
3. Attach FQ-CoDel as the queue discipline on each
4. Bind a floating firewall rule to push traffic through them

Loaded latency dropped from 640 ms to a steady 14 ms. Calls stopped breaking up.

Then — something better

CAKE rolls the shaper, the AQM, and per-host fairness into a single tin. Where FQ-CoDel needed a hand-tuned limiter pair, CAKE took one bandwidth number and a keyword and did the rest — and handled per-user fairness better on a network this size.