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.