root@OpenWrt:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1866.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1866.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1
Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000root@OpenWrt:~# cat /etc/os-release
NAME="OpenWrt"
VERSION="18.06.1"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 18.06.1"
VERSION_ID="18.06.1"
HOME_URL="http://openwrt.org/"
BUG_URL="http://bugs.openwrt.org/"
SUPPORT_URL="http://forum.lede-project.org/"
BUILD_ID="r7258-5eb055306f"
LEDE_BOARD="mvebu/cortexa9"
LEDE_ARCH="arm_cortex-a9_vfpv3"
LEDE_TAINTS=""
LEDE_DEVICE_MANUFACTURER="OpenWrt"
LEDE_DEVICE_MANUFACTURER_URL="http://openwrt.org/"
LEDE_DEVICE_PRODUCT="Generic"
LEDE_DEVICE_REVISION="v0"
LEDE_RELEASE="OpenWrt 18.06.1 r7258-5eb055306f"Thanks for all the information!
So with these values you can expect up to:
172000 * (1500-20-20)/(1500+18) = 165428 Kbps or 165.4 Mbps goodput,
10800 * (1500-20-20)/(1500+18) = 10387Kbps or 10.4 Mbps
Your measurement of 161.8/10.1 is IMHO not that far off this value (100*161.8/165.4 = 97.8%; 100*10.1/10.4 = 97.12 %). You might want to try changing
option iqdisc_opts 'nat dual-dsthost'
to
option iqdisc_opts 'nat dual-dsthost ingress'
as that might allow you to set the download shaping to a higher value (and regain some throughput for most situations).
At a measured goodput of 221.4/12.51the gross rates for the DOCSIS shaper should be at least:
221.4 * ((1500+18)/(1500-20-20)) = 230.2 Mbps
12.5 * ((1500+18)/(1500-20-20)) = 13.0 Mbps
(unless this was caused by powerboost or a similar transient bandwidth grant by your ISP), you might get away with setting the shaper to:
230200 * 0.90 = 207180 Kbps
13000 * 0.99 = 12870 Kbps
(Persoanlly, since I like round numbers I would probably try 200000 and 12000, but that is a policy question you need to answer for yourself)
If you do, please use dslreports speedtests to confirm that experienced latency-under-load (bufferbloat) is still low enough for your taste, otherwise reduce the rates and measure again.
I initially assumed, you route would struggle to reach the configured shaping rate, but it seems that you simply set a low shaper rate voluntarily 
I pay for 200/10 so just went with that, just wanted to make sure it was doing what its supposed to, i get good bufferbloat results but the underload does still get higher than i would like but i think it may be that im with virgin media that use puma6 chipsets. So still get alot of ping spikes.
Sure staying within one's contract sounds reasonable. Now cable ISPs often overprovision
The subscribers' bandwidth, so that the contracted rates are actually achievable as goidput in common Browser-Bäder Speedtests, so why don't you try step-by-step to increase the download shaper rate until the latency under load increase gets larger than you are willing to accept?
Regarding the PUMA-bug, there is nothing sqm will be able to help you with in regard to that bug, you really either need a new firmware that tries to work-around the bug or a new modem with a different non-buggy chipset....
Yes its already about as good as i can get it, still spikes anything between 20-100ms up/down and idle, contract is up soon so i will be moving provider. Its really only for gaming trying to get as good a connection as i can, thanks for your input.
Spikes to 100ms are not good for gaming or VoIP. Try reducing your bandwidth substantially and see if the spikes disappear if so then you can search for the sweet spot if not then you know SQM can't help. For example what do spikes look like at 120/6 Mbps? If they are gone then you could try say 150/8 and zero in etc.
1 Like
Pretty much the same, i know its because of the modem but i cant swap it out, as i said will be going with another provider soon so wont have to deal with it for long. I will be trading bandwidth for a more stable line and i will be able to use a modem of my choice.
Here in the US the FCC in theory prevents providers from limiting your choice of modem. Good luck with finding an alternative.
Good advice, as usual; now in this specific case the known-bugs in the Puma5/6/7 DOCSIS-modem SoC will introduce RTT excursions that SQM will never be able to fix, so sqm can only really be tuned by trying to optimize the average RTT under load, but the residual bursty delay will stay uuntil the firmware is replaced with a firmware implementing a workaround (and for DOCSIS-modems that typically can not be done by the user, the ISP would need to roll this out in his network) or replacing the ISP-modem with a modem not affected by the bug (but not all ISPs offer different modem and/or are willing to provision users' 'private modems).
Yes thats why im moving, the other companys here have not long started allowing customers to use their own hardware, though virgin media do not.
1 Like
Quick question here... I'm wondering about that "ingress" command. Seen it a time or two before, but don't see it mentioned in the Cake Man page or elsewhere. Could you fill us in on what it does?
Regarding cake's "ingress" keyword:
So conceptually a traffic shaper will drop and/or delay packets in a way that the rate of packets leaving the shaper is smaller or equal to the configured shaper-rate. This works well on egress, but for post-bottleneck shaping as is typical for the internet ingress (the download direction) this is not ideal. For this kind of shaping we actually want to make sure that there is as little as possible packet-backspill into the upstream devices buffers (if those buffers where sized and managed properly we would not need to shape on ingress in the first place). And to avoid backspill we need to make sure that the combined rate of packets coming into the upstream device (rarely) exceeds the bottleneck links true capacity. The "ingress" keyword, to the best of my knowledge, now instructs cake to basically try to keep the incoming packet rate <= the configured shaper rate. This probably leads to slightly more aggressive dropping, but this also ameliorates one issue we have with post-bottleneck shaping, namely the inherent dependency of the required bandwidth "sacrifice" with the expected number of concurrent bulk flows. As far as I can tell the more aggressive dropping in ingress-mode automatically scales with the load and hence it shouldake it possible to get away with configuring an ingress-mode rate closer to the true bottleneck-rate, and actually also get higher throughput if only few bulk flows are active.
For further reference I recommend to have a look at cake's source at https://github.com/dtaht/sch_cake?files=1
Hope that helps....
1 Like
Thanks, it does. I tried it out, re-tweaked my own settings with it, before coming back and reading this. And, It seems to help, and allow higher shaping settings, like you described, as well as keeping the latency down even more. At least until my rate moves lower on my cable connection. Right now, it's spectacular.
The suggestion to read the source code wasn't as good for me, since I'm not as code conversant as I would like to be. (or need to be to really dig out what's going on there, despite some commenting)
Don't want to turn this into a thread jack, but someplace, there needs to be a conversation about less documented features like this, assuming there's a few more that might be handy or new. And how and when are good places to use them. Wondering how well it might work if one wanted to try SQM'ing their wifi bottleneck for instance, though that's a challenge....
I just went and added the text above to https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details that should at least give some reference....