> On 20 Sep, 2018, at 4:39 am, Ruben <ru...@vfn-nrw.de> wrote: > > > There's no counter for ecn marked packets in bytes, so it's impossible to > > implement it that way, too. > > > > ECN-Marks is in packets, so everything else need to be in packets as > > well. > > Hmm, so the obvious follow-up question would be "why do you need to have > backlog and number of drops on the same graph?" :) > > I think the answer is obvious: The graph has the purpose to show the pressure > on the qdisc, so backlog is a reasonable number to show, even if combining > backlog with drops is a far fetch from data science standpoint.
I don't see any real conflict between measuring backlog in bytes and marking events in discrete packets per second. You need to provide a dual axis scale to fit them on the same graph, that's all - but you'd probably need to do that anyway, because the units of measurement would still be different. More generally, I have accepted the Codel premise that time is more important for congestion control than either bytes or packets; for a wired link, bytes are closer to a measure of time than packets are (because packets of different sizes can have wildly different serialisation delays and line occupancy). For wifi, aggregation patterns have a bigger effect on time measures than the raw number of bytes involved. There *is* a readout of total backlog packets as well as bytes, just not one per tin. - Jonathan Morton _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
