SQM Errors on install (17.0.1 C1)

I just installed !7.01 Rc1 and SQM. I received the following errors after the section Configuring packages

SQM: ERROR: QDISC codel is NOT useable.
SQM: ERROR: QDISC pie is NOT useable.
SQM: ERROR: QDISC sfq is NOT useable.

The device is a HooToo TM-02 travel router with 8/32mb. The installation did not indicate any other issues and I have yet to configure or test. Can someone please shed some light on what this indicates?

Installing luci-app-sqm (1.1.2-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mipsel_24kc/packages/luci-app-sqm_1.1.2-1_all.ipk.
Installing sqm-scripts (1.1.2-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mipsel_24kc/packages/sqm-scripts_1.1.2-1_all.ipk.
Installing tc (4.4.0-8) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mipsel_24kc/base/tc_4.4.0-8_mipsel_24kc.ipk.
Installing kmod-sched-core (4.4.42-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/rt305x/packages/kmod-sched-core_4.4.42-1_mipsel_24kc.ipk.
Installing kmod-sched-cake (4.4.42+2017-01-21-69449f3c-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/rt305x/packages/kmod-sched-cake_4.4.42+2017-01-21-69449f3c-1_mipsel_24kc.ipk.
Installing kmod-ifb (4.4.42-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/rt305x/packages/kmod-ifb_4.4.42-1_mipsel_24kc.ipk.
Installing iptables-mod-ipopt (1.4.21-2) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mipsel_24kc/base/iptables-mod-ipopt_1.4.21-2_mipsel_24kc.ipk.
Installing kmod-ipt-ipopt (4.4.42-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/rt305x/packages/kmod-ipt-ipopt_4.4.42-1_mipsel_24kc.ipk.
Installing iptables-mod-conntrack-extra (1.4.21-2) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/packages/mipsel_24kc/base/iptables-mod-conntrack-extra_1.4.21-2_mipsel_24kc.ipk.
Installing kmod-ipt-conntrack-extra (4.4.42-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.0-rc1/targets/ramips/rt305x/packages/kmod-ipt-conntrack-extra_4.4.42-1_mipsel_24kc.ipk.
Configuring kmod-ipt-conntrack-extra.
Configuring kmod-sched-core.
Configuring tc.
Configuring kmod-ipt-ipopt.
Configuring iptables-mod-ipopt.
Configuring kmod-sched-cake.
Configuring kmod-ifb.
Configuring iptables-mod-conntrack-extra.
Configuring sqm-scripts.
Configuring luci-app-sqm.

I can't shed much light other than to say i got them too on my wrt1200 v1 w/17.01rc. There is this from the release notes for 17.01 rc -

Improved Networking Support
Smart Queue Management (SQM) minimizes bufferbloat by using the
cake and fq_codel qdisc's.

So maybe LEDE will just be focusing on cake and fq_codel.

The codel, pie, and sfq qdisc's are no longer relevant, and consequently are not bundled in 17.01.0-rc1.

They will not be mentioned in -rc2, so those messages will go away.

Those errors are likely just cosmetic and harmless.

To my knowledge codel, pie and sfq have are not used by the included scripts in SQM, but the software still (unnecessarily) checks for them, as SQM has originally been designed to be extendable and enable writing personal scripts using a wide selection of qdiscs.

Why the error materialised now, is due to the change in kmod-sched and kmod-sched-core contents. Two small "core" qdiscs (htb, tbf) were moved from the larger kmod-sched to kmod-sched-core, and SQM was changed to depend only on the smaller kmod-sched-core (without pie, sfq and codel):

However, SQM source itself still includes those three dropped qidscs in the "check these qdiscs" list:

That is the error that is hopefully fixed by @tohojo or @moeller0 for the next SQM release, hopefully, for 17.01-rc2.

This is unfortunately not that simple to remove as we sytill want to allow users to select sfq, pie and codel in the GUI, if and only if those qdiscs are available so we need to check them. We also use the same function to check availability of qdisc at run time where it is an ERROR if the selected qdisc is not functional. I agree that in RangerZ's case the ERROR label is a bit overeager, and an INFO label might be more appropriate (I still believe we should let the users know).
Mmh, maybe we can set the log-level for that message dependent on whether this is the generic check or whether it is the .qos-script specific one... Let me think about this...

Best Regards

you might have two qdisc lists:

  • "sqm_check_core_qdiscs" fq_codel, cake, (htb, tbf ?) that causes error message if missing
  • "sqm_check_optional_qdiscs" that would be checked and added to the qdisc list if present, but absence would cause no log spam (as they are not used by the included "normal" scripts (simple/cake)

It would be rather straightforward to modify defaults and update-available-qdiscs in that way.

Hi Hnyman,

not that simple, simple.qos and simplest.qos will honor the seected qdisc and use for example pie instead of fq_codel if the user selects pie in the qdisc drop down list. So we really want to populate that drop-down list with all qdiscs we know how to handle. That said in the lost we creare we are missing pfifo_fast and bfifo...
As you point out this will need to be solved by playing with the logging level for the different verify_qdisc invocations. I might have a go at that tonight.

To be explicit, the code in question does not try to detect all qdiscs, but basically to figure out whch of the supported leaf qdiscs are available as we only want our users to select from available qdiscs.

Yeah, those errors are harmless. Can silence them, sure :slight_smile:

PLease note that this just cropped up since we escalated the not useable messages from info to error, as otherwise failures during the attempt to run an actual .qos-script simply failed silently, which seems even worse that the log messages that started this thread. But this is just for perspective on how we got here, I fully agree that we want/need to fix that. Heck we might even just log a single line, listing the missing qdiisc with a pointer which packet might contain them (if they are missing in the first place).

Best Regards

There's an update now that silences the errors during qdisc probing