[LibreQoS] Ack-filtering

[Herbert Wolverson]

Highly un-scientific (we need to let it run for a bit and do a proper
before-after comparison that includes a decent timeframe), but I like the
quick'n'dirty results of testing "ack-filter":
[image: image.png]
We've been having a Bad Network Day (TM), with sudden flooding making us
use some pretty constrained - so our latencies were *really* suffering in
one region. That region just happens to be the worst part of our network
(we haven't finished digesting an acquisition; there's even Bullet M2 omnis
up there!). Lots of relatively low-speed plans, all with big variance
(10/3, 25/5, I found a 5/1 that someone forgot to upgrade!). They seem to
have benefitted greatly. The parts of the network that were doing great -
are still doing great, with very little change.

Just a quick'n'dirty test. I'll try and put something more useful together
tomorrow, when it's had a chance to see how peak time hits it.

(Also, this digging revealed an issue with pping-cpumap in production. It
wasn't tracking enough flows, so the reporting is heavily biased towards
the top-consumers - who are likely to be monitored before the buffer fills
up and it stops counting until stats are read. So I added a "maximums.h"
file to make it easy to set user limits, and made flow-count derive from
that.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221024/5be99abb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 375873 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221024/5be99abb/attachment-0001.png>