QoS Fail

[brendan_kearney]

i was playing with some QoS settings on my linux router, and ultimately wanted to undo what i buggered. since the tc command does not write any settings to disk, i figured a reboot would do. once rebooted, i am still having some buffering issues with audio/video. video will play fine, while muted, but once i unmute the audio the video buffers and eventually the whole stream freezes. this did not happen prior to my mucking around with QoS, so i am fairly sure that this isn't some other, intervening event or issue.

would any kind soul have insight into how i can be sure that i have eradicated QoS settings (and classes, queues, etc) from my router? any help is appreciated.

 

[Paladin]

I haven't played with it myself but this page seems to have decent options to view the current tc rules and to clear them https://commandmasters.com/commands/tc-linux/

 

[brendan_kearney]

oddly, i seem to have the router settings turned back to default. and the issue persists, so i think i need to look in a new direction. if i set my settings, and then change them, does an upstream device take notice? could i be in a situation where the other end of the link is "behind" in what is going on? like QoS has to be performed on both ends, to be truly effective. since i change my stuff, does the other end need to be changed (back)?

 

[Paladin]

Assuming the 'other end' is an ISP, no, they care naught for your QoS settings (which is why QoS is kind of dumb outside of your own network). I would pop in some basic off the shelf router (TPLink or whatever) and test with that really quick to see if it might be an unrelated ISP issue or something. If it goes away, Maybe deploy a new VM router and see if it is better out of the box. It might be some kind of config file you didn't realize was getting changed and that can be hard to track down unless you have a backup image of the router from before any tinkering.

 

[steelghost]

This is a classic example (and I'm talking to myself as well here) of not taking a backup of your settings before fiddling with something. Then when you can't get it working as you want you say "oh I'll just go back to where I was", but you find out that the config management is not as "deterministic" as you thought it was. That, or the behaviour you're observing is actually unrelated to the change you made!

And yeah - the 'only' real benefit to QoS in a home network environment is ensuring that your preferred devices get bandwidth and maybe your less preferred don't, when there's line contention. That said, it can make some connections (especially highly asymmetric ones) much more usable than they otherwise would be. When we had 200/20 cable in our old house, if someone kicked off a big download while I was on a video call it all went to shit. Once I put some QoS rules prioritising TCP ACKs and DNS traffic - worked fine. Late I found I got basically the same benefits by just having fq-CoDel SQM on the WAN link, and that was less complicated.