<div dir="ltr"><div>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":</div><div><img src="cid:ii_l9n9zhw40" alt="image.png" width="558" height="287"><br></div><div>We've been having a Bad Network Day (TM), with sudden flooding making us use some pretty constrained - so our latencies were <i>really</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>(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.)<br></div></div>