Community discussions

MikroTik App
 
dtaht
Member Candidate
Member Candidate
Topic Author
Posts: 209
Joined: Sat Aug 03, 2013 5:46 am

tuning the hardware (Wifi or ethernet) tx ring buffersize to reduce bufferbloat

Wed Jul 27, 2022 4:39 pm

It would be useful to be able to deduce and reduce the hardware tx ring size on wifi, especially on older (6) "stable" releases of mikrotik, to reduce latency and jitter under multi-station contention. This appears to presently be a number in the 128-256 packet range, which is overkill even for mcs-15 - and at lower MCS rates more commonly achieved in the field, like mcs-12, far, far too big, where 32 would be closer to right, even with packet aggregation.

Many years ago, I gave a pretty funny demo as to why such a large packet pfifo was a such a horrible thing on wifi with more than one station: https://www.youtube.com/watch?v=Rb-UnHDw02o&t=1667s

Fixing this more thoroughly than just reducing the fifo size turned out to be hard (the fq-codel'd fixes for per station scheduling and queueing landed in linux around linux 4.12 and have been improved ever since, and regrettably some bugs cropped up in it recently that we're still fixing in openwrt and kernel mainline). In general it was my hope that those writing proprietary drivers would take inspiration from our work and either adopt these APIs or leverage the same ideas in their code, which is written up in the online book "bufferbloat and beyond" (Polifi, and "Ending the anomaly") - https://bufferbloat-and-beyond.net/ - we managed to achieve vastly better PtMP throughput and latency for wifi in general.

But! a knowlegable ISP merely being able to tune down the tx ring size in RouterOS6 for wifi makes an overlying qdisc such as sfq with a per IP filter and larger quantum, work better, as well as token bucket rate limiting, especially for a PtMP radio. It's just one number...

For routerOS7 I'm not sure what you are doing for wifi?

For routerOS7 I HOPE (and would like to confirm) y'all are now using the BQL facility for ethernet. I worry, if this was the case, that "only-hardware-queue" would then end up underbuffered, rather than overbuffered.

In present linux ethernet drivers, the "BQL" facility automatically limits device ring size to a very small number, and makes the overlying hardware queue more effective. Very happy to see people switching to running fq_codel or cake at the native rate, which combined with BQL is a huge win, at all achievable native speeds.

Who is online

Users browsing this forum: No registered users and 22 guests