router: CAKE shaper on WAN egress at 63M to kill upstream bufferbloat
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
c41e2490b2
commit
f6b6f6993e
1 changed files with 21 additions and 0 deletions
|
|
@ -122,6 +122,27 @@ in
|
|||
# false = keep the lease and re-REQUEST it (INIT-REBOOT).
|
||||
SendRelease = false;
|
||||
};
|
||||
|
||||
# CAKE shaper on WAN egress. eno1 carries fq_codel at 1Gbit line
|
||||
# rate, so it never actually engages: the uplink is ~70Mbit, which
|
||||
# means the real queue forms upstream in TalkTalk's kit where we
|
||||
# can't touch it. Shaping just under measured line rate pulls that
|
||||
# queue down here, where CAKE's per-flow fairness keeps sparse
|
||||
# latency-sensitive traffic (games, VoIP) from sitting behind a bulk
|
||||
# upload. Measured by router-speedtest: 8.73-9.52 MB/s up, i.e.
|
||||
# ~70Mbit floor; 63M is 90% of that.
|
||||
#
|
||||
# NAT=true so flow isolation resolves real LAN hosts rather than
|
||||
# lumping the whole house behind one post-NAT address. Kernel default
|
||||
# FlowIsolationMode (triple-isolate) is host-aware, so this matters.
|
||||
#
|
||||
# Egress only: 500Mbit down is far harder to saturate and shaping it
|
||||
# would need an IFB device for not much gain.
|
||||
cakeConfig = {
|
||||
Parent = "root";
|
||||
Bandwidth = "63M";
|
||||
NAT = true;
|
||||
};
|
||||
};
|
||||
"20-lan" = {
|
||||
matchConfig.Name = "eth0";
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue