This should work, or alternatively:
/etc/init.d/sqm stop ; /etc/init.d/sqm start
Ah yes, thanks.
a netgear R7800 will simply not be able to traffic shape with cake even close to 500/100, sorry.
People reported higher shaper rates using simplest_TBF.qos/fq_codel on that model, but still not sure whether that will do 500/100 reliably, as traffic shaping at high rates is quite CPU intensive.
Your options are:
a) stick to your router and prioritize throughput: just disable aqm
b) stick to your router and prioritize latency under load: iteratively test up to which rate sqm reliably works**, but that might well be below even 200/100.*
c) get a more powerful router that allows sqm at 500/100
*) Just as an illustration, I was traffic shaping my 116/35 link to 49/33 as that was the highest sqm rate my router allowed reliably, for my use cases and on my link, that resulted in a more usable link, but that depends on a link's latency under load characteristics and the subjective latency under load tolerance, so is a subjective policy decision each network admin needs to make individually, there is no right or wrong here.
**) Start with 100/50 and first increase the upload until you see less increase in throughput and more increase in latency under load. After you found a reliable value for the upload repeat with the download.
It won't, 500 MBit/s is close to its maximum without any shaping at all - so any additional efforts will push it over the cliff.
1 Like
So, my router, isn't powerful enough to handle sqm for my hired speed, is that it?
Without sqm, yes - with sqm it's way too slow (around 190 MBit/s are to be expected).
RPi4, r4s or x86_64 would be a match (I'm using an ivy-bridge c1037u on a 400/200 MBit/s connection).
I missed this post:
To reply:
I'm not sure what I should answer here but My ISP is providing me Fiber Optic internet. Is this what you want to know?
my cat /etc/config/sqm is
config queue 'eth0.12'
option enabled '0'
option interface 'eth0.12'
option download '490000'
option upload '95000'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '0'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '0'
option itarget 'auto'
option etarget 'auto'
option linklayer 'none'
config queue 'wan'
option debug_logging '1'
option verbosity '5'
option squash_dscp '1'
option squash_ingress '1'
option ingress_ecn 'ECN'
option egress_ecn 'NOECN'
option interface 'eth0.12'
option download '490000'
option upload '95000'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '1'
option qdisc_really_really_advanced '0'
option itarget 'auto'
option etarget 'auto'
option enabled '1'
option linklayer 'ethernet'
option overhead '44'
my tc -s qdisc is
# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth0 root
Sent 32602026229 bytes 55653512 pkt (dropped 1361, overlimits 0 requeues 10870)
backlog 0b 0p requeues 10870
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 32602026229 bytes 55653512 pkt (dropped 1361, overlimits 0 requeues 10870)
backlog 0b 0p requeues 10870
maxpacket 1514 drop_overlimit 0 new_flow_count 18745 ecn_mark 1
new_flows_len 0 old_flows_len 0
qdisc mq 0: dev eth1 root
Sent 231542087224 bytes 163903648 pkt (dropped 0, overlimits 0 requeues 89449)
backlog 0b 0p requeues 89449
qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 231542087224 bytes 163903648 pkt (dropped 0, overlimits 0 requeues 89449)
backlog 0b 0p requeues 89449
maxpacket 1514 drop_overlimit 0 new_flow_count 104177 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth1.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 801d: dev eth0.12 root refcnt 2 bandwidth 95Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 44
Sent 323519497 bytes 318850 pkt (dropped 24, overlimits 95101 requeues 0)
backlog 0b 0p requeues 0
memory used: 181888b of 4750000b
capacity estimate: 95Mbit
min/max network layer size: 28 / 1500
min/max overhead-adjusted size: 72 / 1544
average network hdr offset: 14
Tin 0
thresh 95Mbit
target 5ms
interval 100ms
pk_delay 50us
av_delay 10us
sp_delay 7us
backlog 0b
pkts 318874
bytes 323553913
way_inds 85076
way_miss 299
way_cols 0
drops 24
marks 0
ack_drop 0
sp_flows 10
bk_flows 1
un_flows 0
max_len 20076
quantum 1514
qdisc ingress ffff: dev eth0.12 parent ffff:fff1 ----------------
Sent 882934260 bytes 788851 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 801e: dev ifb4eth0.12 root refcnt 2 bandwidth 490Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 44
Sent 902735967 bytes 775818 pkt (dropped 13033, overlimits 55645 requeues 0)
backlog 0b 0p requeues 0
memory used: 1556972b of 15140Kb
capacity estimate: 490Mbit
min/max network layer size: 42 / 1500
min/max overhead-adjusted size: 86 / 1544
average network hdr offset: 14
Tin 0
thresh 490Mbit
target 5ms
interval 100ms
pk_delay 43us
av_delay 11us
sp_delay 7us
backlog 0b
pkts 788851
bytes 921362006
way_inds 17
way_miss 310
way_cols 0
drops 13033
marks 0
ack_drop 0
sp_flows 9
bk_flows 1
un_flows 0
max_len 67398
quantum 1514
Tested, wired, with the above settings.
I was hoping for the ISP's name, Fiber Optic Internet is close (it appears clear, but a lot of ISPs hide copper based technologies like DSL of DOCSIS/cable behind fiber-this fiber-that names to emphasize that part of the access network is already switched to fiber).
But I think we found the problem already, your link is too fast for your router so you need to make compromises as listed above...
Judging from your posted waveform speedtest, I guess something like 180000/90000 might work as shaper rates....
You cana visit my ISP site at meo.pt
After lunch, I'll run some more tests!
But will that limit my download/upload speeds to those values?
Yes, and to be preciae, the gross rate, best case goodput as measured by a speedtest is going to be a few percentage points small still.
So, I think I'll just won't use it... I think I'll be better like that, no? I want to be able to enjoy my hired speed!
That is a decision you need to make. IMHO there is no right or wrong here. Given your router's performance in relation to your link speed you really have to pick your point in the continuum between:
minimal latency-under-load-increase at a steep throughput sacrifice
versus
maximal throughput at worse latency-under-load-increases
what place in this continuum you prefer depends entirely on how you perceive the trade-off you strike.
Personally, I would probably try each of the following configuration or about a week:
- no SQM at all
- SQM with 0/95 Mbps, that is effectively only enable a traffic shaper on the egress for which your router should be powerful enough
- full SQM with 95/95 Mbps
and then try to figure out which of the three performed best for my appications.
Well in that case your options are 1) and 2) of the above list and/or buying a more powerful router (you still could use your R7800 as AP for WiFi). But that is pretty much your decision to make. If you prefer throughput that is certainly a valid policy decision for you to make for your network.
I am amazed how a router like this can't handle higher internet speeds. I thought I had a pretty powerful router. I'm really frustrated right now" 
Well to be honest traffic shaping is computationally expensive (not necessarily that it needs a large amount of CPU cycles and more that when it needs the CPU it needs the CPU with minimal delay...
Most commercial routers for ens-users are facing the same problem (without even trying traffic shaping) and try to work around the issue using special accelerator components. The R7800 has, IIRC two NSS cores that can be used from within a few special builds of OpenWrt that might allow it to punch above its CPU's weight class... (two problem with accelerators typically are: a) no support for/by the mainline Linux kernel and hence no support in OpenWrt (with exceptions, see NSS builds) b) often accelerators restrict the generality of Linux's network stack, so allow to offload a few costly operations to dedicated hardware but only if you use exactly those few operations with the configuration supported by the offload engine).
Don't be, doing something interesting with network packets at > 500 Mbps line rate simply takes processing power and most home routers really were designed for a world in which something like 100/40 or 250/40 was considered the high end, no real wonder that such designs start to struggle when faced with 500-1000 Mbps or more.
That said, when I tested my turris omnia (from 2017 IIRC) it allowed NAT, firewall, SQM at 550/500 Mbps with bidirectionally saturating traffic, (it will hence not allow traffic shaping for symmetric 1 Gbps links), so there are router's out there capable of doing work at your speed....
1 Like
I might even be misunderstanding the traffic shaping thing. Right now, I don't see much problems while dowloading or opening sites. My biggest problem is with IPTV. Because I use something shady (don't want to give too many details due to its nature, xD, hope you understand what I mean) to have access to more contents, many times my TV images simply freezes, sometimes, for ever, and I have to either restart my IPTV conenction, or turn off wifi and turn it back on after a while or change the VPN server, etc. I thought trffic shaping could help with this problem, but in this case, probably it has nothing to do with it!
But if it doesn't have nothing to do with it, I don't know why my TV image freezes so many times, almost in a daily basis.
That should be easy to test, configure sqm for 90/90 Mbps (so 90000/90000 in the config file, so that your router should be able to handle the combined rates) and see whether that shows the same IPTV issues or not. If yes, traffic/shaping SQM is not going to help, if no, it might be time to test the available options...
The thing is that I have just renegotiated my ISP contract and they offered me 500Mbps / 100 Mbps (from previous 200 Mbps / 100Mbps) and now to have to go down back to 200, kinda sucks.
But, even so, you're saying that this router cannot cpu handle the link speed. However, I'm testing with the 495000 / 95000 and I can't see more than 40% load on the cpu!
Another thing, I don't know why, but when I run /etc/init./sqm stop I get this output:
# /etc/init.d/sqm stop
SQM: Stopping SQM on eth0.12
SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev eth0.12 ingress
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: Error: Invalid handle.
SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev ifb4eth0.12 root
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
Then, if I repeat it:
# /etc/init.d/sqm stop
Command failed: Not found
Fair point, the 90/90 recommendation above is only for testing, so orthogonal to the question what you do permanently...
How do you measure load? You really should be looking at the idle% value and if that get too close to 0 (say often in the 5-10% range) you are likely CPU bound, and it is enough if one of your (2 or 4?) CPUs gets saturated, if that is the CPU that handles SQM.
I have no first hand experience with R7800, but believe @slh's number as something in that range has been brought up multiple times in the past.
Intersting, no idea yet what might cause this.
What was the output of:
ifstatus wan | grep -e device
again?
I checked with top and looked for %CPU. There was a time that a process called ksoftirqd/0 spiked to 40%, but not for long.
This is my ifstatus wan | grep -e device
root@OpenWrt:~# ifstatus wan | grep -e device
"l3_device": "eth0.12",
"device": "eth0.12",
root@OpenWrt:~#
Edited;
btw, I am removing one of the sections I had in my sqm config file because it was not needed, I guess.
And will run some more tests!
Edited 2;
Ok, I just tested the new config file:
root@OpenWrt:~# cat /etc/config/sqm
config queue 'wan'
option enabled '1'
option interface 'eth0.12'
option download '450000'
option upload '95000'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '1'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '0'
option itarget 'auto'
option etarget 'auto'
option linklayer 'ethernet'
option squash_dscp '1'
option squash_ingress '1'
option overhead '44'
option debug_logging '1'
option verbosity '5'
root@OpenWrt:~#
and idle never go under 48%, getting this:
But still it cuts off at 200 Mbps.