On such a slow link I would recommend: option egress_ecn 'NOECN'
Leave this at its default of 2047 this does not work as one intuitively assumes, for cake with linklayer_adaptation_mechanism 'default' this is ignored, but I think it is still a good idea to get this right. And the same applies to:
Well test it with something like:
a) flent (the gold-standard) but requires to servers on the internet (maybe @dtaht could help out here?)
b) The waveform on-line speedtest with latency under load/latency under working conditions measurements
c) Ookla's speedtest app for android or ios
If sqm is set well stuff like a speedtest during a VoIP call or a videoconference should work well (but note with your 630 Kbps upload you are in the "manage the pain" territory already)
About the qosify configuration I can not say much (since I am not using qosify myself), but the principle behind prioritization is still quite simple:
For every packet that get processed/transported faster/earlier other packets will need to be transported slower/later, this is going to work reasonably well if only a smallish fraction of packets are actually treated to higher priority (moving stuff to the background priority is less problematic, but that tin has very little guaranteed throughput, so if only put stuff in there you are willing and ready to wait for)...
This should be 96...
Also only use one method to instantiate cak on pppoe-wan, either sqm OR qosify, only one can be active at the same time (the later running one will silently disable the other one I assume).
Let's tackle that in a different thread, after we got the 9/0.6 Mbps version operational, okay?
I am confused, I thought we are talking about a ~10/0.7 ADSL link here
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.
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
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).
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).
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?
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?)
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.
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.
)