Where is this package in the nconfig menu? Cant find it.....
Building from master and not seeing it in any of the available package menu
Qosify DNS feature seems to depend on dnsmasq (looking at the code), I am looking to run only unbound with odhcpd. Any one have idea what does it take to make qosify work with unbound? I am aware that dnsmasq can be run serial to unbound, but its not so great for performance. It will be nice to for qosify to support unbound as well.
1 Like
You must install llvm package in your host OS, then make menuconfig, Advanced configuration options -> BPF toolchain (use host llvm toolchain), and then Base System -> Qosify
2 Likes
Thanks for this, got it working.
@nbd https://git.harting.dev/anonfunc/upload-baker
It would be nice if you can implement something similar. What do you think?
Or like this?
OpenWrt users have put together various solutions that generally work - see here:
Still a work in progress. It's not easy and we'd value your input on that thread if you want to help test and improve (assuming you have a variable rate connection).
4 Likes
Same question
will this package get a luci interface in future?
You can have both installed (SQM and Qosify), but not enabled simultaneously.
If you look at the thread there are a lot of examples of how to make it work, but I think it's not that hard.
First, you need to edit your /etc/config/qosify file with your interface parameters and start it with
/etc/init.d/qosify start
(optional) Enable automatic startup
/etc/init.d/qosify enable
and you can test if everything is ok executing
qosify-status
It should show the interface with the ingress and egress status, if not, check the interface name and that is not disabled, repeat until you can see the ingress and egress status, after that edit the defaults with your own dscp markings:
/etc/qosify/00-defaults.conf
If you want to test if your packets are correctly tagged, a simple way is just to open a streaming service defined in the config file, like netflix (you can find some examples in the thread), capture the traffic in the router using tcpdump, and dump it to a file, open it with wireshark, and you should see the packets tagged as AF41.
I'm describing how to run Qosify in a generalized way, there are some parameters not touched here that you must know to make it work efficiently (your bandwidth speed, overhead, etc).
2 Likes
In my case it would be a lte link and unstable docsis connection (vodafone germany 
)
1 Like
I note that aside from giving people fun knobs to twiddle, I remain dubious as to qosify's actual value. Does anyone have a repeatable test demonstrating it to be:
A) doing something measurably useful remarking packets at the ISP link then transiting over wifi?
B) improving VOIP MOS
Etc?
Value:
- Sets up CAKE qdiscs as requested
- Allows easy marking of inbound and outbound traffic based on remote IP or port
- Allows DSCP marks based on DNS names, filling the void left since dnsmasq 2.87 has not been released with nftables support yet
- Hopefully works faster as a eBPF module than traditional iptables rules for marking traffic
What tests are needed beyond those tests that prove CAKE works as advertised?
1 Like
Some application that actually shows a benefit from the dscp marks generated vs a vs just plain cake fq.
So more of a question of the value of diffserv{n} versus the value of qosify? Interesting. You might crush the souls of a whole generation of tweakers if besteffort is the answer! (or is 42 the answer?)
2 Likes
Reading it implicitly -- you're saying WMM is useless?
lol -- this is a big claim. We're getting into "x"-truther territory here. Like someone in the above post, it could be aptly named "best effort truther" or "rtt truther".
there are no "claims" made here, but I am certainly in search of the truth. My goal is to find a test (or tests) multiple parties can run that reliably demonstrates what qosify can do to improve traffic behaviors. Over here is a really excellent test and plotting script that could also be applied to the isp link or to wifi.
irtt client --dscp=0xfe -i3ms -d5m an_irtt_server
In my cloud I presently have irtt and flent servers in toronto, sydney, singapore, atlanta, dallas, fremont, de (germany), and london on the .starlink.taht.net subdomain.
You can rewrite the dscp via qosify (irtt listens and transmits on udp and udp6 port 2112), and run other traffic against it.
I had stated somewhere on this thread that I think the biggest benefit to be had is setting the dscp on the wifi client to land in the VI queue (CS5 on linux). I certainly theorize that the "sparse station optimization" will largely take care of getting out packets rapidly to the client from the AP, but I am willing to be proven wrong with data. I could assert another point, re wifi, in that it is so fundamentally unreliable that diffserv markings or no, unless we make it more fundamentally reliable, most of the "missed shot" problem should be pointed at the wifi stack and no amount of twiddling dscps will help.
Given the hell we have been going through to just get the BE queue right in wifi:
it would actually be helpful if more folk were beating up the other wifi queues in whatever manner they like. Notably, stadia or an equivalent over the wifi VI queue would be good.
Another interesting test is to see if various dscp markings survive transit across the internet. (usually only ecn does)
I'm also on record as thinking that "background" is the most useful (in theory) diffserv class.
3 Likes
Be careful what you ask ;). There was a time when my macbook when using AC_VI or AC_VO in a bidirectional throughput test was essentially starving the AP for tx-ops*. Which makes me think one should first test how well up/down sharing works if a client is set to use AC_VI or AC_VO for a significant portion of its traffic.
This was within a RRUL test, so all 4 ACs likely where involved, so things might be different if just AC_VI is used, but I still would recommend to first confirm that that works...
Side-note: I still think the AP should monitor air time usage and adaptively change which AC it uses per default not to be starved by stations.
I strongly agree that actually testing what happens if people go crazy with the VI queue would be good!
1 Like
hi,
i am far from being expert on this subject, but my feeling is that there are different use cases vs expectation what qosify can or cannot do. so maybe first we should agree what qosify (or other similar tools) are aiming for, e.g.
- is it a plugable "algorithm" for network devices to act as general improvement to reduce latency, bufferbloat, do qos/aqm,
- is it meant to improve wifi traffic,
- is it meant to help with custom prioritization and improve fairness in regards of internet traffic,
- etc etc
there are many use cases and what each tool can cover should be set first then can compare against other similar tools in my opinion.
if you ask what qosify value is than maybe it is not the tool you looking for according to your test scenarios, maybe it is, i don't know.
But "typically*" based on the many question in this site people looking for solution for three kind of problems:
- reduce internet latency - by people who are using online games. they playing with few games with well defined traffic patterns (kind of) but suffering from latency.
- fair internet access sharing with priority - people/households working from home and need to share a (limited) internet access among work traffic, video conferences, online school, movie/music streaming service, which services running in the same time parallel. they probably want to prioritize work traffic daytime and then movie streaming at night.
- crowded wifi - many wifi clients connecting to very few to single AP, which causing wifi slowness in general.
(*) am sure there are many other uses case, it is not a comprehensive but a very subjective list based on what I feel as the questions recurring all the time.
Also, there is a huge expectation difference between very technical people (like you, you are talking about VI queue) and average joe (like me) in regards how easy the tool should be to use. people asking when qosify will get a luci menu for example.
for me the value in qosify is for example the very easy (**) setup and the way how it can connect/mark egress and ingress traffic for the same flow.
(**) it is relatively easy, the kind of reverse logic (remote ip + remote port) tends to confuse people, as they create very sophisticated but wrong configs for their local listening ports ...
so for me qosify is a configuration tool for custom packet marking to control internet facing traffic (***). maybe it is not the primary purpose, not sure.
(***) wish it would add features like local-ness config schema (local ip/ports) to better control traffic when only my near end is known but remote end is not (e.g. VoIP).
my 2 cents. if reached so far thanks for reading 
1 Like
Very simple thing:
Watching netflix with highest Qualifying during download a game without Client Limitation. Daily Business here
2 Likes