Re: [Cake] Munin-Plugins
> On 20 Sep, 2018, at 4:39 am, Ruben 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
Re: [Cake] Munin-Plugins
Hey Toke,Am 19.09.2018 11:11 schrieb Toke Høiland-Jørgensen :Ruben writes: > Hey Toke, > > Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen : > > > Ruben writes: > > > Hey Toke, > > > > Thanks for your fast response! > > > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > > > > Ruben 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 regardsRuben ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Hey Dave,Am 19.09.2018 19:01 schrieb Dave Taht :On Wed, Sep 19, 2018 at 2:11 AM Toke Høiland-Jørgensen wrote: > > Ruben writes: > > > Hey Toke, > > > > Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen : > > > > > > Ruben writes: > > > > > Hey Toke, > > > > > > Thanks for your fast response! > > > > > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > > > > > > > Ruben 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. This only works for general internet traffic. It would probably confuse user with say VoIP gateways.I think it's better (if we really want to go this way) to use the average package size of the past packages per queue by diving the sent bytes by the sent packages.But I'm still not convinced, that this is the best option we got. How difficult is just a conter on the cake-side?Best regardsRuben___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
On Wed, Sep 19, 2018 at 2:11 AM Toke Høiland-Jørgensen wrote: > > Ruben writes: > > > Hey Toke, > > > > Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen : > > > > > > Ruben writes: > > > > > Hey Toke, > > > > > > Thanks for your fast response! > > > > > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > > > > > > > Ruben 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 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Ruben writes: > Hey Toke, > > Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen : > > > Ruben writes: > > > Hey Toke, > > > > Thanks for your fast response! > > > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > > > > Ruben 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 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Hey Toke,Am 13.09.2018 21:12 schrieb Toke Høiland-Jørgensen :Ruben writes: > Hey Toke, > > Thanks for your fast response! > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > Ruben 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. > > 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 :) Alright.Best regardsRuben ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Ruben writes: > Hey Toke, > > Thanks for your fast response! > > Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen : > > > Ruben 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 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Hey Toke,Thanks for your fast response!Am 13.09.2018 12:27 schrieb Toke Høiland-Jørgensen :Ruben 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. > 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.Best regardsRuben___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
Ruben 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 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Munin-Plugins
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.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.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.Best regardsRubenAm 11.09.2018 04:22 schrieb Ruben :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/941Feel 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 regardsRuben___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] Munin-Plugins
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/941Feel 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 regardsRuben___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
