I've been having some latency issues and I eventually found about SQM. http://www.dslreports.com/speedtest shows without SQM I get around 12 Mb/s download and around 1 Mb/s upload. I'm seeing 100ms or less bufferbloat on download but around 2000ms or more of bufferbloat on upload with SQM. Can anyone help me fix this bufferbloat?
I installed "luci-app-sqm" and configured it as below.
Interface name: eth0
Download speed (kbit/s) (ingress) set to 0 to selectively disable ingress shaping: 91200
Upload speed (kbit/s) (egress) set to 0 to selectively disable egress shaping: 7500
Queuing disciplines useable on this system.: cake
Queue setup script: piece_of_cake.qos
Which link layer to account for: Ethernet with overhead
Per Packet Overhead (byte): 28
My network is as follows. The devices then their roles
Comcast ISP ---> Motorola SB6121 Cable modem ---> WD My Net N750 ---> TP-Link TL-WDR 3600
12/1 Package ---> Stock cable modem ---> Main router wifi + ethernet + DHCP + IPv4/IPv6 ---> Dumb AP + DHCP Client
Ok new settings below give me great bufferbloat results at DSLReports but slow connection speeds of 70 kilobit/s down and 139 kilobit/s up
Interface name: eth0.2
Download speed (kbit/s) (ingress) set to 0 to selectively disable ingress shaping: 11400
Upload speed (kbit/s) (egress) set to 0 to selectively disable egress shaping: 950
Queuing disciplines useable on this system.: cake
Queue setup script: piece_of_cake.qos
Which link layer to account for: Ethernet with overhead
Per Packet Overhead (byte): 28
SOLVED!. Kind folks at the #lede-dev irc channel at Freenode pointed out my wrong ingress and egress settings. Also pointed out that I had the interface set as "eth0" when my WAN port is "eth0.2". A reboot was needed in my case to make sure SQM wasn't running any old sessions after all my changes. After reboot my speeds are as expected! 10.68 megabit/s down and 765.5 kilobit/s up and DSLReports shows little to no bufferbloat, 20ms or less. Good to go, thank you all for the help and the open source firmware.
The correct final settings are as below.
Interface name: eth0.2
Download speed (kbit/s) (ingress) set to 0 to selectively disable ingress shaping: 11400
Upload speed (kbit/s) (egress) set to 0 to selectively disable egress shaping: 950
Queuing disciplines useable on this system.: cake
Queue setup script: piece_of_cake.qos
Which link layer to account for: Ethernet with overhead
Per Packet Overhead (byte): 28
Great! If you still have the nerves to dig a little deeper, have a look at https://lede-project.org/docs/howto/sqm, especially the last section, about making cake sing and dance... to get the most out of your shaper.
Ethernet with Overhead: SQM can also account for the overhead imposed by VDSL links - add 8 bytes of overhead. Cable Modems (DOCSIS) are known to typically use 28 bytes of overhead in the upstream direction but only 14 bytes in the downstream direction. If your version of SQM only supports to specify one value for the overhead, select 28 Bytes… UPDATE: while the reported numbers are not wrong per se, it turned out that the user traffic shaper mandated? by DOCSIS systems only account for L2 ethernet frames including the frame check sequence (FCS), so the 2017 recommendations for cable users is to set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 bytes FCS).
I understand that if I use EuroDOCSIS with 28 bytes then I should change it to 18 bytes?
If that's a yes then why not that edit this and leave the value of 18, why confuse users?
Well, for one 28 is not "wrong" just not the relevant number and we have been "promoting" 28 bytes for some time so that silently changing the number to 18 would confuse people that had selected 28 before. I guess after a few months simmering we should clean this up, (potentially by relegating the rationale/time course into a footnote). Does that make sense?