No buffer bloat, 'standard' SQM/Cake help with VOIP?

Hi all,
I don't have buffer bloat that I can see (less than 2ms change under load), being on an apparently well implemented PPPoE fiber to the home service at 200/100.

However with my previous cheapo router I would often get issues around voice calls etc...now this may have been down to patchy wifi coverage.

The question being, will the 'piece of cake' Cake SQM setup (which I have deployed) help prioritize 'realtime' traffic at the expense of 'bulk' traffic like downloads/p2p etc.

Or given that there isn't really any 'congestion' between the router and my internet link any kind of QoS scheme isn't going to change much?

I'm just wondering if there is some way to protect realtime traffic if I have a high speed bulk download/uploads using 199/99 of the 200/100 link...

If you can identify the IPs/ports/TCP/UDP of those voice packets, I'd use the simple QoS to "dedicate" some bandwidth the size of a voice call.

So, if that link is truly "under-subscribed", the rule would never "hit" or "activate" anyways.

1 Like

Thanks for the input. I've been testing with SQM on and off...pulling 25Mb/sec downloads while streaming a bunch from youtube at 1080 and 4k...the only difference I ever notice is a slight buffering delay if I change to unbuffered parts of the video on youtube WITHOUT SQM. With SQM it doesn't happen at all.

I think all my previous issues were down to a weak router...now I have a much more powerful router + OpenWRT it seems to be revealing that my actual internet connection could be kickass :D.

I cannot think of any tests to try and stress it even further.

Both cake and fq_codel give sparse flows a slight boost over flows that already have packets in the queue. At 200/100Mbps a typical VoIP flow with it's approximate 100/100kbps will be treated as new and eligeable for the sparse flow boost unless you are constantly and heavily overloading your link.
This simple heuristic works amazingly well.

1 Like