Is it possible somehow do specify which types of packets should not be dropped?
Based on whatever?
Thanks
No. Not really, at least not generally. But assuming your very important packets(VIPs) come from an inherently rate limited source, you could use one of the diffserv modes like diffserv4 you need to make sure, that the VIPs carry the correct DSCPs. In addition, if you enable ECN for the VIP flows on both endpoints, packet loss gets even less likely even for capacity seeking protocols like TCP...
Maybe you describe the reason why you think you need undroppable packets in the first place, as that will allow for a better discussion.
Well im just guessing and putting 2 and 2 together really.
Im watching/in the background twitch streams 24/7 when im awake really. I want that to never drop packets, i rather have anything else drop packets really.
And now im getting the occasional buffer on the streams im watching.
I have 1000/1000mbit bidirectional fiber so i should be able to fix that.
Mmmh, yes, except for the fact that not all packet-loss is bad 
In fact for any non-constant bitrate algorithm, specifically for any traffic flows designed to scale up to the available bandwidth packet drops are an important signal to tell the application to reduce its sendiing rate since the current rate exceeds the path's capacity. This is even true to a degree for video streams, at least those that will automatically scale the bitrate/quality based on the detected capacity.
According to https://blog.twitch.tv/de-de/2015/12/18/twitch-engineering-an-introduction-and-overview-a23917b71a25/ twitch transcides streams to HLS which then is both adaptive and using TCP. IMHO you should not really be looking for removing all packet loss for your twitch streams, maybe try to minimize them so that they have fewer negative artifacts, but removing drops altogether (unless twitch servers support ECN) is not going to be feasible).
I am really not sure that getting rid of all packet drops even for the twitch streams is feasible or even desirable.
I would as a test, try to configure cake for per-internal-IP fairness and run the twitch streams on an otherwise unloaded computer (that way there should be 1000/(number of concurrently active machines in your internal network Mbps basically reserved for twitch). If this gets rid of the artifacts it might be worth inquiring further, if the artifact still happen, then the minimize drops is probably not going to help anyway.
1 Like
I dont know if thats what i did or not to be honest but.
Adding
ingress queueing disciplines dual-srchost"
made everything amazingly good, i had 600 concurrent "http downloader max threads count" using startrinity continuous speed test, thats the ultimate test ive been using.
i had 10 streams with 1080p60fps running without lag while using 900mbit with startrinity!!!
What is this magical setting
That is most of the way, sure, telling cake to distribute available capacity by the IP address of the remote server, which for a speedtest will work, because that way the 600 speedtests combined will be given same share of the link as the 10 video streams combined (and if the videos are served from different servers the 600 speedtests will be given the same share as each individual video). Please note that these are the theoretical limits, if as to be expected the videos do not use up all of their share, that is redistributed among the remaining greedy flows, aka the speedtests, which hence should "mop up" the rest of the capacity, but will be reigned in if new video starts or videos streams require higher throughput.
I would recommend something slightly different:
"Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully.":
nat dual-dsthost ingress
"Advanced option string to pass to the egress queueing disciplines; no error checking, use very carefully":
nat dual-srchost
That way the sharing will try to share equally between the internal hosts, basically making it simple to isolate functions on different machines, such that e.g. a high-flow-count torrent machine will leave your twitch videos mainly unaffected. Note that to get to the NATed internal IP addresses, you need to add the "nat" keyword...
But note that this is not going to work if you run the 600 flow torrent client on the same end-host as the twitch streaming client.
By default sqm aims for flow-fairness, that is all concurrently active flows get an roughly equal share of the available capacity, so with 600 torrents and one twitch stream on your link each flow only will get roughly 1000/601 = 1.66 Mbps, which for a high quality video stream probably is too little. Add to this that starting flows take a while to be reigned in by sqm and you will inuitively see why running this will not work well.
Adding dual-serc
Ye thats what im trying to achieve, both twitch and 95% of the traffic in this household is from the same IP, mine.
Like i said the "dual-srchost" did some magic, will continue to evaluate.
Im still seeing some weird behavior though, even with very little happening trafficwise. the stream im watching have a 0.5sec hiccup here and there, its not like im gonna die from it, but i like trying to optimize
edit: when the hiccups happens im monitoring with "tc -s qdisc" and there are no dropped packets, so i dunno whats up
Simply don't ;), or if you must, use network namespaces* to make sure the torrent endpoint gets a different IP address than the twitch receiving application.
That said, there are ways to make this work, but for ingress traffic these require some pretty heroic measures that are not supported in sqm-scripts out of the box, have a look at https://forum.openwrt.org/t/ultimate-sqm-settings-layer-cake-dscp-marks-new-script/53209 for how to solve that issue. Note that the per-internal-IP fairness mode does not require this level of in direction, since cake can peek into the conntrack database to see the internal IP addresses, in a way that tc can not and hence all the trickery to get the cake shaper instantiated after iptables/nftables had a go at incoming packets.
Well, as I tried ot explain, this basically gives you by external IP-address fairness, might be fine, but since the external IP addresses are not under your control and not guaranteed to be static this is going to be a hit-and-miss heuristic. E.g. usually torrent requests come from other users most from a different external IP address, so what works well for your test (with probably just a few IP addresses in use by the measurement servers) might actually not work that well with real-life torrenting.
Well, you can also look at cake's estimates of delay, but the delay might already occur on the path to your router, so inside the internet cloud and completely out of your control.
*) I want to note that in theory that should work under Linux, but I zero first hand experience how to set that up, so please do not ask me how to do that
1 Like
Actually im trying to read and learn about this.
I believe i know how to "activate" diffserv3, 4 or 8 but im having trouble finding documentation that are easy enough for me.
I dont know how to "assign" traffic to a certain tin for example, learning how to create iptables and find out what kind of "match" arguments can be used and so on.
Got a tip for a semi-noob (i work in IT and have always dealt with computers but not linux and nitty gritty of networking)?
Yes, for cake activation consists out of adding the proper keyword to the cake instantiation and you are done. The way this works is either by using DSCPs (the trick is to use the correct DSCPs to steer packets into the desired cake tier/tin, looking at the source of cake help figuring out that DSCP to tin mappings for the different diffservN keywords). Alternatively, I believe cake will also allow to steer packets into the tins by using firewall marks (fwmarks) explicitly. In both cases you need alternative means to identify packets to mark/steer them to the intended tins, and on ingress that is a bit tricky, since cake runs before iptables/nftables and hence you either need tricks or need to use tc and work without knowing the internal IP addresses.
The thread I linked to in the earlier mail has some good information (interleaved with millions of posts) about that topic.
And @ldir has a really clever trick in which you only need to identify and dscp mark outgoing packets (which should be easy) and apply the same marking effectively to incoming packets of the same "connection" (as tracked by conntrack). But I have little first hand experience.
Yes, if the world would be perfect you would not need to bother with iptables, since nftables has much nicer syntax than iptables, but alas, OpenWrt's firewall3 is based on iptables and @ldir's cool module is also iptables only. I think you will find some examples for how to identify and mark in the above mentioned thread.
1 Like
Thank you for being an active and helpful member ( i see you everywhere )
Im trying this out on a VM, im getting
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
Do you know why?
Edit: Nevermind, thank you 