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":

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