[Cake] Munin-Plugins

[Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 801 bytes --]

Re: [Cake] Munin-Plugins

[Georgios Amanakis]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Thank you for this! I run my in on my router and will give this a try.

Georgios

On Mon, Sep 10, 2018, 10:22 PM Ruben <ruben@vfn-nrw.de> wrote:

> Hey guys,
>
> I wasn't aware that there's any munin-plugin for cake out there... so I
> wrote two simple ones:
>
> https://github.com/munin-monitoring/contrib/pull/941
>
> Feel free to let me know what your thinking, critism is highly appreciated.
>
> Also I thought to write one to track the used bandwidth, the avg latency
> and the active flows.
>
> Tell me what you would like to see, I'm not that deep in that topic yet.
>
>
> Best regards
>
> Ruben
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 2013 bytes --]

Re: [Cake] Munin-Plugins

[Toke Høiland-Jørgensen]

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?

> Also I haven't found details on the man page, but haven't looked in
> the code how exactly flows are defined for the new 2 level fair
> queueings.

A flow is a flow (hash on the regular 5-tuple). Unless you install
custom tc filters, in which case a flow could be anything you want it to
be...

> I would like to show hosts as well as flows in a graph, in the various
> states as summary as well as per tin. But hosts aren't shown in the
> statistics. But they could be helpful to see unexpected rises if
> someone is abusing the system.

Hmm, guess we could do "number of hosts per tin" accounting as well as
flows. But it would be bloating up the already bloated statistics. But
on the other hand, they are already quite bloated, so another pair of
stats maybe wouldn't make much of a difference?

Does anyone else have an opinion on this?

-Toke

Re: [Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 3245 bytes --]

Re: [Cake] Munin-Plugins

[Toke Høiland-Jørgensen]

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?

>     > Also I haven't found details on the man page, but haven't looked in
>     > the code how exactly flows are defined for the new 2 level fair
>     > queueings.
>
>     A flow is a flow (hash on the regular 5-tuple). Unless you install
>     custom tc filters, in which case a flow could be anything you want it to
>     be...
>
>     > I would like to show hosts as well as flows in a graph, in the various
>     > states as summary as well as per tin. But hosts aren't shown in the
>     > statistics. But they could be helpful to see unexpected rises if
>     > someone is abusing the system.
>
>     Hmm, guess we could do "number of hosts per tin" accounting as well as
>     flows. But it would be bloating up the already bloated statistics. But
>     on the other hand, they are already quite bloated, so another pair of
>     stats maybe wouldn't make much of a difference?
>
>
> How important is a row more or less? It's quite verbose already (what
> I like) - as long as the number is available without much additionally
> work needed.

It's the additional complexity of recording the stats internally in cake
I'm worried about, not the extra lines of output :)

-Toke

Re: [Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 4306 bytes --]

Re: [Cake] Munin-Plugins

[Toke Høiland-Jørgensen]

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?" :)

-Toke

Re: [Cake] Munin-Plugins

[Dave Taht]

On Wed, Sep 19, 2018 at 2:11 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> 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?" :)

A reasonable approximation of backlog in packets is achievable by
dividing by 1000.

> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 4480 bytes --]

Re: [Cake] Munin-Plugins

[Ruben]

[-- Attachment #1: Type: text/html, Size: 3772 bytes --]

Re: [Cake] Munin-Plugins

[Jonathan Morton]

> On 20 Sep, 2018, at 4:39 am, Ruben <ruben@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