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] Cake vs fq_codel and c/burst on an ER-X bridge
thx! On Wed, Sep 19, 2018 at 6:28 AM Sebastian Moeller wrote: > > Hi Dave, hi All, > > so I tried to run with this idea and prototyped something into the > burst_by_duration branch at the sqm repository. Would be interested to hear > whether that does "the right thing" with your APU or on other's devices? The > key variable is TARGET_BURST_DUR_MS in defaults.sh. Let me know how this > performs for you (or whether there are bugs). As Toke proposed elsewhere I > will try to streamline that branch to only configure burst size by duration > so expect some changes in organization, but it should keep functional. > > Best Regards > Sebastian > > > On Sep 11, 2018, at 10:20, Dave Taht wrote: > > > > What I "fixed" was on the apu2 with the burst/cburst change, I went > > from completely bottlenecked on one softirq to having 3 eat cpu, and > > from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?) > > driver. The edgerouter X is a dual core, and you did see a small > > improvement in throughput, but I'd hoped for more. > -- 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
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] Cake vs fq_codel and c/burst on an ER-X bridge
Hi Dave, hi All, so I tried to run with this idea and prototyped something into the burst_by_duration branch at the sqm repository. Would be interested to hear whether that does "the right thing" with your APU or on other's devices? The key variable is TARGET_BURST_DUR_MS in defaults.sh. Let me know how this performs for you (or whether there are bugs). As Toke proposed elsewhere I will try to streamline that branch to only configure burst size by duration so expect some changes in organization, but it should keep functional. Best Regards Sebastian > On Sep 11, 2018, at 10:20, Dave Taht wrote: > > What I "fixed" was on the apu2 with the burst/cburst change, I went > from completely bottlenecked on one softirq to having 3 eat cpu, and > from 400mbps to 900mbps. Now, that's a quad core and the e1000 (?) > driver. The edgerouter X is a dual core, and you did see a small > improvement in throughput, but I'd hoped for more. ___ 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
