I'm trying to install luci-app-sqm on the latest LEDE snapshot for my device, but getting kernel dependency errors. How do I fix this?
I downgraded to 17.01 final so that I wouldn't have this dependency issue. However, I'm unfamiliar with SQM apparently.
I have a nominal 100/10 cable internet connection, with F grade bufferbloat according to DSLreports. When measured with no SQM, it reads as 117/12. I tried 95% of these numbers with cake/piece of cake, and for some reason it drops my download to 10mbps and upload to ~7mbps.
Anybody have recommended SQM settings with DIR-860B1?
Have a look at https://lede-project.org/docs/howto/sqm if you did not so far. Also we currently seem to have some not fully understood issues with some router's where the WAN port is connected to a switch, so you might want to try setting the download shaper bandwidth to 0 (this disables ingress/download shaping, but you still should have working egress shaping).
I tried that earlier as well. No effect.
As a side note, does Archer C7 V2 have the same issue with WAN switches? I actually use that presently as a LEDE AP, with DIR860 B1 serving as LEDE router. I could flip that around if SQM works well on the Archer
What exactly did you try earlier, setting download bandwidth to zero? It wou;d be great if you could post the output of:
cat /etc/config/sqm
tc -d qdisc
tc -s qdisc
as well as a link to a dslreports speedtest you did that shows the lowered bandwidth, please. I would recommend to get a free registration at dslreports, after which dslreports allows individual configurations of the speedtest, my recommendations: enable High-Res bufferbloat testing and compression dodging, set the number of ingress/egress streams to 8 or 16 (start with 16 and scale back to 8 if you get errors during the test), and finally set the ingress/egress test duration to >= 30 seconds).
Sorry, no idea; it is currently not fully clear what is the root cause of the WAN though switch issues is, as far as I can tell it only affects some users, but not all on switched WAN router models. I seem to be unable to recreate the issue with the two router's I have at my disposal, so "my hands are tied...
Currently, I believe the best action would be to better understand what is causing your specific bandwidth loss as first priority, and keep the switch to the C7 as plan B....
I did try setting download to 0. I also read somewhere that setting the interface to specific WAN port (eth0.1 or eth0.2) might help. In my testing, that didn't have any effect.
Here are the results without SQM on: http://www.dslreports.com/speedtest/12707106
and with: 0/12 set on Cake/Layer of Cake with 28bytes overhead: http://www.dslreports.com/speedtest/12707234
Results of cat:
config queue 'eth1'
option interface 'eth0'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option script 'layer_cake.qos'
option qdisc_advanced '0'
option upload '12000'
option download '0'
option enabled '1'
option linklayer 'ethernet'
option overhead '28'
tc -d qdisc:
qdisc noqueue 0: dev lo root refcnt 2
qdisc cake 8006: dev eth0 root refcnt 2 bandwidth 12Mbit diffserv3 triple-isolate rtt 100.0ms raw
linklayer ethernet overhead 28
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev eth0.1 root refcnt 2
qdisc noqueue 0: dev eth0.2 root refcnt 2
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 cake 8006: dev eth0 root refcnt 2 bandwidth 12Mbit diffserv3 triple-isolate rtt 100.0ms raw
Sent 67954286 bytes 85765 pkt (dropped 6752, overlimits 232573 requeues 0)
backlog 0b 0p requeues 0
memory used: 362880b of 4Mb
capacity estimate: 12Mbit
Bulk Best Effort Voice
thresh 750Kbit 12Mbit 3Mbit
target 24.2ms 5.0ms 6.1ms
interval 119.2ms 100.0ms 12.1ms
pk_delay 659us 22.5ms 482us
av_delay 58us 7.4ms 53us
sp_delay 6us 54us 6us
pkts 134 92131 252
bytes 13931 78195199 26325
way_inds 0 226 0
way_miss 32 1954 7
way_cols 0 0 0
drops 0 6752 0
marks 0 0 0
sp_flows 0 0 1
bk_flows 0 0 0
un_flows 0 0 0
max_len 187 11762 930
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 eth0.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth0.2 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Oha, that sounds weird, could you describe the 860B1's port layout a bit more in detail. If eth0 is the only true interface from the SoC to the switch and it uses two VLANs to attach WAN and LAN to the switch, the instantiating sqm on the physical interface below those two VLAN interfaces is certainly the wrong thing to do. In my hypothetical? case both ingress and egress would be shaped to the minimum of your defined bandwidth as WAN egress traffic is LAN ingress traffic, plus for concurrent traffic things will be even worse. I hope that eth0.1 and eth0.2 are just weird ways to name two independent interfaces. Please feel free to elaborate about the specifics of your router. This is pretty important to get right, but also impossible without user input...
This shows that your system encounters giant (meta-packets), cake should be able to deal with those, but you might want to disable TSO, GSO and GRO (on all interfaces) to test whether these cause issues. See https://forum.openwrt.org/t/issue-with-ipv6-6in4-and-sqm/1348 for some more information about GRO disabling...
For DOCSIS/cable links the current recommendation is to use 18 bytes for the overhead (as that is the overhead that the DOCSIS mandated user-traffic shaper accounts for, the fact that DOCSIS adds more overhead is irrelevant for sqm-sxripts configuration).
You might want to have a look at the current version of https://lede-project.org/docs/howto/sqm, espevially the "sing and dance" section at the end on how to get the most out of cake (which admittedly is less urgent than getting it to work in the first place 
)
Best Regards
Here is my switch layout, no changes from default that comes with the LEDE build for this device:
and here is the interfaces screen:
Let me know if there's any other information I can provide about the switch layout.
Thanks, looking at http://www.t-firefly.com/download/FireWRT/hardware/MT7621.pdf and your information seems to indicate that the WAN port is truly via the switch. I have no clue though whether there are two links from the rest of the SoC to the switch or just a single one. Be that as it may, with eth0.2 being your WAN interface you should instantiate sqm on eth0.2 and make sure to remove all other instances on say eth0...
Hope that helps
I'm actually not sure which is my WAN interface. Both my WAN 6 (eth0.2) and
WAN (eth0.1) have IP addresses. One is IPv6 and one is IPv4 from my ISP.
According to your posted screen shoot of the "interfaces screen" both wan and wan6 use eth0.2, so that should be the interface to instantiate sqm-scripts on. Due to the uncertainty, I would recommend you set the shaper on eth0.2 (and remove/disable all other shaper instances for testing) to 50% of you lowest bandwidth or 5Mbps/5000Kbps in your case, first set egress to 5000 and ingress to zero and run a speedtest*, then set ingress to 5000 and egress to zero. This test should help figure out whether the ingress/egress definitions of your set-up are flipped in relation to the internet. Next set the confirmed uploading direction to 5000 and the confirmed downloading direction to 50000. If this does not yield acceptable bufferbloat control we can/should take the debugging from there.
If the bufferbloat control is decent, you can iteratively start to increase the bandwidth until bufferbloat stats to reach leves you are unhappy with; I would initially leave download at 50% and increase upload until bufferbloat starts to increase again, and only then do the same with downloading. Also note shaping downloading after the true bottleneck link, as we are forced to do is more approximate than upload shaping, so I would recommend to also test the result you were happy with using 8 or 16 downloading streams with say 32 downloading streams, just to make sure you are happy with the tradeoff.
Best Regards
P.S.: were the full contact information above posted on purpose, if not I believe you still should be able to edit them...
*) I recommend to use https://www.dslreports.com/speedtest get a free registration first, then you can configure your speedtest parameters (you get to the configuration page by clicking the cog button). Here are my recommendations:
-
set "No. download streams:" to 16 (if this causes errors during testing change both to 8)
-
set "No. upload streams:" to 16 (if this causes errors during testing change both to 8)
-
check the "Hi-Res BufferBloat:" checkbox (on the detailed results page of a finished test click the Idle, Downloading, and Uploading labels underneath the bufferbloat bar graph to get results from all individual latency probes per test phase to better understand the bufferbloat issues)
-
set "Upload duration:" to 30
-
set "Download duration:" to 30
-
check the "dodge compression: " checkbox
-
if you perform a test post a link to the detailed results page here in the forum (much nicer than just overview images)
Fixed most of my issues by setting WAN interface to eth0.2
http://www.dslreports.com/speedtest/12941467
Definitely my upload was the issue, but I've got numbers that are fairly acceptable at this point with cake/layer of cake.
Okay, this looks pretty nice. The zoomed in version of the Downloading Bufferbloat graph, shows that you have one nasty latency spike around time point 280; but the rest seems decent. This spike could be caused by either of:
a) your browser/test machine doing something else and not servicing the browser-tab long enough (your browser CPU is rated as fast so this is somewhat unlikely)
b) the download shaper is set a bit too high (also unlikely as that would cause not such a localized spike)
c) DOCSIS 
In a cable segment up- and download bandwidth is shared between all active users, this spike might simply be caused by other users transiently using up all bandwidth (this kind od variable upstream congestion is something that sqm-scripts can not really handle well).
All in all, I would repeat the speedtests at a few different time points (pick those when you are actually intend to use the network regularly) and see how well the shaper parameters deal with the encountered traffic pattern in your segment. With a bit of luck you are set for good. Ah, in case you start to notice bufferbloat again in the future, just repeat the measurements and adjust the shaper settings accordingly. (Tangent: there are project out there that can use a DVB-C usb stick to actually measure the downlink utilization of a <DOCSIS 3.1 cable segment, this can also help to figure out where potential spikes come from, unfortunately I have no link for that...)
Best Regards