Hey Toke,

Am 19.09.2018 11:11 schrieb Toke Høiland-Jørgensen <toke@toke.dk>:

Ruben <ruben@vfn-nrw.de> writes:

> Hey Toke,
>
> Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen <toke@toke.dk>:
>
>
>     Ruben <ruben@vfn-nrw.de> writes:
>
>     > Hey Toke,
>     >
>     > Thanks for your fast response!
>     >
>     > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen <toke@toke.dk>:
>     >
>     >
>     >     Ruben <ruben@vfn-nrw.de> writes:
>     >
>     >     > Hey guys,
>     >     >
>     >     > I've already mentioned this in a response to dtaht on GitHub, but
>     here
>     >     > again for everyone:
>     >     >
>     >     > I was wondering if it's possible to extend the tin statistics by
>     >     > packets for backlog.
>     >
>     >     Why do you need packets when there's already bytes?
>     >
>     > Easy: dtaht requested a packets graph with ecn marks, which is also
>     > packets, so backlog as bytes do not fit, backlog as packets do.
>     >
>     > The idea was to do a multi-graph which is one graph with combined
>     > stats for all tins and sub graphs for all tins.
>     >
>     > On the main graph a backlog in packets is available, but I would need
>     > to leave out the backlog for the tins, which is somewhat confusing.
>
>     Why not just do both backlogs in bytes?
>
> 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.

Best regards

Ruben