Qosify: new package for DSCP marking + cake

Well, that in itself is not sufficient evidence to assume the applicable overhead is 1500-1492=8.

That however is interesting. Which combinations of shaper rate and per-packet-overhead did you try and how did you assess "goodness"?

Will it have an app for LuCI?

I'm trying to test Qosify but struggling to make it running.
How can I verify cake is active?
Is below config (/etc/config/network) ok?

config defaults
        list defaults /etc/qosify/*.conf
        option dscp_prio CS5
        option dscp_icmp CS6
        option dscp_bulk CS0
        option dscp_default_udp CS4
        option bulk_trigger_timeout 5
        option bulk_trigger_pps 100
        option prio_max_avg_pkt_len 500
        option interfaces wan #tested as well with eth0.2
/cut/
config interface 'wan'
        option proto 'dhcp'
        option peerdns '0'
        option hostname '*'
        option device 'eth0.2'
        option name 'wan'
        option disabled '0'
        option bandwidth_up 20mbit
        option bandwidth_down 300mbit
        # defaults:
        option ingress 1
        option egress 1
        option mode diffserv4
        option nat 1
        option host_isolate 1
        option autorate_ingress 1
        option ingress_options ""
        option egress_options ""
        option options "overhead docsis"

So far with display filter set to ip.dsfield.dscp != 0 in wireshark I can mostly see ARP.

Shouldn't you edit /etc/config/qosify?

yeah, good point :slight_smile: somehow I thought changes should be applied to /etc/config/network.

No...

In terms of cpu resources is it lighter than sqm?

as I understand it this is a system to help you adjust DSCP tags, it doesn't do queue management by itself, so it's basically an add-on to SQM, therefore not lighter in any way.

1 Like

Actually, it launches the cake qdisc (like SQM would do), and you do not need SQM at all.
In a sense, this is a replacement for SQM.

5 Likes

Sorry, I should have said it isn't a replacement for cake. SQM is more than cake but it's the main dish so to speak.

4 Likes

Since sqm's run time costs is really just the instantiated qdisc hierarchy's CPU requirements, qosify should be identical to layer_cake.qos/cake in sqm. In theory simplest.qos/fq_codel might be a bit less CPU-hungry, but the recommended SQM configuration with layer_cake.qos or piece_of_cake.qos will be just as CPU demanding. By the way is not actually the (flow-queueing) traffic scheduler or the AQM part that is so CPU-intensive, but the traffic shaper, and there is not much difference in the CPU cost of the available shapers (TBF, HTB, cake, HFSC).

4 Likes

Two different devices (mamba, rango) running same build, exact same /etc/confi/qosify, reboot,:

  • on mamba, qosify is running w cake loaded.
  • on rango, qosify process is listed in ps, cake is not loaded, there is no logread message daemon.info qosify: start interface wan. Issuing /etc/init.d/qosify restart | reload fires thiings up correctly.

Option option ingress_options "wash" makes a significant throughput difference in my environs, cable with docsis 3.1 modem; option ingress_options "besteffort wash" seemed to play about the same.

1 Like

Mmmh, could you run a packet capture for ingress traffic on the WAN side and check the DSCP values of those packets, please? Some ISPs mark considerable fractions of traffic CS1 (I believe this was reported for ComCast in the past) which ends up in cake's lowest priority tin and will see little throughput if there is traffic in the other tins.

besteffort will in deed make less work than the dual-XXXhost modes, but at the cost of not offering per IP fairness.

I just pushed another big qosify update:

  1. alias is renamed to class now, to better reflect its use. The old syntax is still supported for now.
  2. there is now a qosify-status script, which shows qdisc stats for all interfaces (egress and ingress)
  3. bulk/priority flow detection can now be configured per class (as requested by @moeller0)
  4. icmp defaults to best-effort now
7 Likes

So, if I wanted to use Qosify as it is at the moment...

I don't need to select luci-app-sqm if building my own, right? I just select, build, configure as needed and enable Qosify. Is this correct?

Correct. If you're building your own, you should leave out any other sqm-scripts related packages. You also need an LLVM toolchain. The easiest way is if you download the llvm-bpf tarball from the snapshot build of any target and unpack it directly into your OpenWrt source directory.

2 Likes

when i try to install the package i returned this error

Command failed: Request timed out

do you know why?

and the system log reports this

Sat Nov 20 08:18:18 2021 daemon.info procd: Instance qosify::instance1 s in a crash loop 6 crashes, 1 seconds since last crash

Did you build it yourself, or did you use the snapshot? Which version and which target did you use?
Please run qosify -o | nc termbin.com 9999 and send me the link.

Thanks for the reply,
i used the snapshot

OpenWrt SNAPSHOT r18117-ea5fce3f46 / LuCI Master git-21.322.38385-6507b1f

the target is

ramips/mt7621

I am attaching the log generated by qosify -o | nc termbin.com 9999

log

What's the version of the qosify package installed on your device?