> On 22 Feb, 2017, at 13:12, Pete Heist <[email protected]> wrote: > > Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as > far as latency is concerned. I will make full results available later, but > for now, here are two plots for the rrul test
The RRUL test, when viewed in Flent, only shows the latency induced by one flow (bulk) on another (ping). This is influenced mainly by the flow-isolation and priority-queue mechanisms, not by AQM. Where AQM helps is the effect of a flow on its *own* latency. A bulk flow benefits relatively little from reduced latency, and mainly in the area of loss recovery; it also wants to operate in (or very near) the saturated regime as much as possible. A latency-sensitive flow, by contrast, wants to avoid the saturated regime and its induced latency completely, and will accept higher packet loss to achieve that. Cake keeps the inter-flow induced latency down to very near its theoretical minimum, given certain practical constraints such as timer and CPU-scheduling latency. That’s mostly why you don’t see a latency difference in RRUL. The other major factor is that RRUL loads all tins with bulk data, which means the Voice tin in particular is running in deprioritised mode. - Jonathan Morton _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
