[LibreQoS] Ack-filtering

[Herbert Wolverson <herberticus@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1287 bytes --]

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.)

[-- Attachment #1.2: Type: text/html, Size: 1512 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 375873 bytes --]