Setting up SQM / Cake correctly

I set up SQM / Cake through Luci, and would like to check that it is correcty set up...

In Luci, I enabled SQM, assigned it to WAN (eth1), set up my download (11500) and upload speed (2000), both at roughly 90% of the actual test reports values. My queue discipline and setup scripts are "cake" and "piece of cake", respectively, and the parameters for link layer adaptation are ADSL with an overhead of 44.

Here is the output of

tc -s qdisc show dev eth1

...

 qdisc cake 8007: root refcnt 2 bandwidth 2Mbit besteffort triple-isolate rtt 100.0ms raw 
  Sent 731135 bytes 2576 pkt (dropped 1, overlimits 1264 requeues 0) 
  backlog 0b 0p requeues 0 
  memory used: 11200b of 4Mb
  capacity estimate: 2Mbit
                  Tin 0
   thresh         2Mbit
   target         9.1ms
   interval     104.1ms
   pk_delay       7.0ms
   av_delay       855us
   sp_delay         8us
   pkts            2577
   bytes         732884
   way_inds           1
   way_miss         403
   way_cols           0
   drops              1
   marks              0
   sp_flows           2
   bk_flows           1
   un_flows           0
   max_len         1749

 qdisc ingress ffff: parent ffff:fff1 ---------------- 
  Sent 380473 bytes 3830 pkt (dropped 0, overlimits 0 requeues 0) 
  backlog 0b 0p requeues 0

And here is the output of

tc -s qdisc show dev ifb4eth1

...

qdisc cake 8008: root refcnt 2 bandwidth 11500Kbit besteffort triple-isolate rtt 100.0ms raw 
 Sent 1042245 bytes 5155 pkt (dropped 0, overlimits 2597 requeues 0) 
 backlog 0b 0p requeues 0 
 memory used: 39680b of 4Mb
 capacity estimate: 11500Kbit
                 Tin 0
  thresh     11500Kbit
  target         5.0ms
  interval     100.0ms
  pk_delay       180us
  av_delay        58us
  sp_delay         7us
  pkts            5155
  bytes        1042245
  way_inds           3
  way_miss        2118
  way_cols           0
  drops              0
  marks              0
  sp_flows           0
  bk_flows           1
  un_flows           0
  max_len         1643

Can I assume that SQM/Cake is installed correctly and is working, based on the above?

Those are normal output texts, nothing special in them.

You should burden it with some speed tests, and see that a modest amount of packets get dropped (as that is what cake does for traffic control...).

I ran the Ookla speedtest and maybe 1-2% of packets got dropped during high load.

Great thanks for the confirmation!

I just wanted to be sure that everything is installed properly before I run some speed tests and change parameters values.

Mmm...

I performed a speed test and the actual download and upload speed are above the upload and download speed I set in SQM... Also, bufferbloat is significant (rating "D"), although cake is supposed to be enabled...

I have subsequently disabled SQM and run the speed tests, with the same results (ie same down/up speed, same bufferbloat) then when Cake is supposed to be active.

So, either cake is not SQM/active when it says it is, or is not performing what it is supposed to...

How does one goes about debugging these things?

@deuteragenie When I run dslreports.com/speedtest with cake/piece of cake and SQM setup I will get an A+ rating. How are you connected to ADSL - is it via a modem supported in LEDE or are you using an external ADSL modem connected via PPPoE? Packet fragmentation might be an issue.

I am connected through the Internet via a modem/router, and am using DHCP between the Archer C7 (which is running LEDE / Cake) and that router.

I cannot use PPPoE between the modem/router and the Archer C7, because the telco kindly disabled that feature a while ago (for free, and without asking my permission :).

To the best of my knowledge, the telco is using PPPoE over ATM (not too sure how I can test that...).

So it can be that this setup is causing trouble (certainly not ideal...), but the thing is that I got very good results on the TP Link 842Nv3.1 with the same setup.

@deuteragenie, have a look at https://github.com/moeller0/ATM_overhead_detector this should give you an idea about the encapsulation actually used on an ATM/AAL5 link. If you are not too unlucky this should help answer whether "PPPoE over ATM" is the correct assumption (it should also be capable of detecting VLAN tags on the dsl link).

Best Regards

@moeller0
Great thanks for the ATM detector tool. I'll try to run it later this week.

@deuteragenie Just thinking about your different devices. Have you eliminated wifi as a potential source of the problem in your testing? Many 802.11ac implementations suffer from bufferbloat.

No, both routers were tested through wifi.
I will try to repeat the tests wired, but my understanding is that both device use the same driver.