Hi Philip, I’m familiar with the technique of prioritising ACKs to maximise performance. The Firebrick is not sophisticated enough to have this feature or indeed any proper QoS, a limitation that is a shame and I would happily pay for a software upgrade. It does however have a very simple strategy of prioritising all small packets, aimed at VoIP, so ACKs will presumably be assisted by this? I don’t know what to do about piggybacked ACKs though.
This is how I get poor latency figures, bufferbloat of 120 ms typically, but up to 400ms in unusual situations, and max rtt off the scale occasionally (over 500ms I think) in odd cases. I can run the usual-case bufferbloat by reducing the egress rate in the tx rate limiters by 1 or 2% below the rate for the usual best tx-only case max throughput figure. An upstream rate reduction of 1-2% or so is literally unnoticeable, doesn’t seem to actually worsen things at all, just reduces the RTT right down towards the ultimate minimum, which is 50ms my spreadsheet tells me that an RTT if around 150ms -nwhich is higher than necessary - should keep upstream tx queue bubbles to effectively zero and ensure that upstream tx is truly flat out when it’s supposed to be.