<div dir="ltr"><div>I just busted a guy laughing at your annotations. Tahhnk you. <br></div><div><br></div><div>There's been a long "misery metrics" thread elsewhere, about how measuring customer satisfaction was more important than packet loss or bandwidth or the other statistics we so often try to interpret.</div><div><br></div><div>Over here, for example, was this bug: <a href="https://github.com/rchac/LibreQoS/issues/126#issuecomment-1286061009">https://github.com/rchac/LibreQoS/issues/126#issuecomment-1286061009</a> <br></div><div><br></div><div>where the OP applied a change that "saved cpu", but in-observably hurt the customer experience, until a few days went by,</div><div>and they "felt" the change for themselves, and complaints had gone up. <br></div><div><br></div><div>Proactively engaging with users to ask how their subjective experience has got better or worse, after making a change, is one way to get feedback. Others include eating your own dogfood, and active measurements like the flent tests, crusader,</div><div>etc. <br></div><div><br></div><div>The ack-filter, should, in general, speed up slow start, which is a good thing in a fully FQ'd and codeled environement.</div><div>It also accelerates additive increase, same benefits.</div><div><br></div><div>Downsides include that the TCPs on the other side have to interpolate more. <br></div><div> <br></div><div><br></div></div>