<div dir="ltr"><div dir="ltr">> Presently (in v1.3.), robert (in grafina?) is summing drops + marks.<br>
which is a good idea, however perhaps drops, marks and drops+marks<br><div>
would be better.</div><div><br></div><div>Yup, in InfluxDB for the stats by Tin (diffserv4) we display true drops as (trueDrops = ecn_mark + drops - ack_drops). But we don't do it by sub quite yet.<br></div><div>And ok, drops, marks and drops+marks can be shown instead - by subscriber or by Node (AP/Site).</div><div>Dave - is it ok if we graph this data as a percentage of packets sent? So for drops, drop / sent_packets ? I just imagine that would make comparing different subscribers' connections easier.<br></div><div><br></div><div>Question for all - is having drops / marks/ drops+marks by subscriber/circuit worth the extra modest InfluxDB CPU use? Or should we just show those stats by AP/Node?<br></div><div>If preseem currently offers such stats at a subscriber level we can do the same, just wanna be sure I'm not overtaxing CPU.<br></div></div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 24, 2022 at 11:14 AM Dave Taht via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Some of the context of my request for libreqos on vs off is from here,<br>
presentation in the wee hours, wed morning.<br>
<br>
<a href="https://www.linkedin.com/feed/update/urn:li:activity:6989281945868283904/" rel="noreferrer" target="_blank">https://www.linkedin.com/feed/update/urn:li:activity:6989281945868283904/</a><br>
<br>
On Mon, Oct 24, 2022 at 9:48 AM dan via LibreQoS<br>
<<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
><br>
> we also have a bunch of 25/5. It would be nice to get some more detailed numbers from ookla tests.<br>
<br>
+1! We've argued methods with many a provider, and ookla and samknows<br>
are new to this game.<br>
<br>
As one example I don't know if they use decimal or binary mbits!<br>
<br>
...<br>
<br>
ack-filtering in the libreqos case can and will drop acks in both<br>
directions, due to the structure of how htb<br>
works in this scenario, at any bandwidth ratio. I *think* it does very<br>
little harm but I would use the ack-filter<br>
not the aggressive ack filter out of caution.<br>
<br>
Secondly if you are gathering drop statistics from the higher level<br>
htb categories, total drops will go WAY up,<br>
and it is best to use the cake drop, ack_drop outputs statistics directly.<br>
<br>
ack_drops have nothing to do with congestion control and should be<br>
ignored in most cases.<br>
<br>
Also I keep hoping more will pull out ecn marks separately. Public use<br>
is way up by e2e transports, and I worry that a high ecn ratio is a<br>
e2e network error, which might show up as a big backlog.<br>
<br>
Presently (in v1.3.), robert (in grafina?) is summing drops + marks.<br>
which is a good idea, however perhaps drops, marks and drops+marks<br>
would be better.<br>
<br>
An inverse log scale is needed to plot marks, drops, and ack_drops.<br>
<br>
I'll always be of the opinion that it's best to run cake on egress at<br>
the cpe, first, doing all this work before it hits the wire.<br>
Are any of you doing that? Openwrt/dd-wrt/firewalla/mikrotik 7.2?<br>
<br>
>We also have a lot of Eero units out there, so watching for the eero speed test would also be great.<br>
<br>
eero 5s have cake (and fq_codel on the wifi), eero 6s have a somewhat<br>
buggy fq_codel offload:<br>
<br>
<a href="https://www.reddit.com/r/eero/comments/u7xm83/gen_2_sqm_vs_gen_3_sqm_stick_with_gen_2_if_you/" rel="noreferrer" target="_blank">https://www.reddit.com/r/eero/comments/u7xm83/gen_2_sqm_vs_gen_3_sqm_stick_with_gen_2_if_you/</a><br>
> On Mon, Oct 24, 2022 at 10:31 AM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>><br>
>> > sniff DNS for those speed test lookups and trigger a packet capture for x duration?<br>
>><br>
>> That's a good idea (I think there's a service somewhere for finding speedtest<br>
>> servers?). We're discussing testing the ack-filter feature right now, and something<br>
>> similar would work well for that. (We have a bunch of 25/5 and similarly asymmetric<br>
>> connections, in theory it'll help...)<br>
>><br>
>> On Mon, Oct 24, 2022 at 10:31 AM dan via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>><br>
>>> sniff DNS for those speed test lookups and trigger a packet capture for x duration?<br>
>>><br>
>>> On Mon, Oct 24, 2022 at 9:27 AM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On Mon, Oct 24, 2022 at 8:20 AM dan <<a href="mailto:dandenson@gmail.com" target="_blank">dandenson@gmail.com</a>> wrote:<br>
>>>> ><br>
>>>> > Dave, I think that 'bouncing' is more CPU time in the browser. I don't think it's indicative over what's actually happening.<br>
>>>><br>
>>>> A simultaneous packet capture and wireshark plot of the RTTs would<br>
>>>> also be helpful.<br>
>>>><br>
>>>> ><br>
>>>> > On Mon, Oct 24, 2022 at 9:09 AM Dave Taht via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>>> >><br>
>>>> >> On Mon, Oct 24, 2022 at 8:02 AM Robert Chacón via LibreQoS<br>
>>>> >> <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>>> >> ><br>
>>>> >> > I can run an Ookla test in the middle of the night with LibreQoS off for a bit.<br>
>>>> >><br>
>>>> >> Groovy.<br>
>>>> >><br>
>>>> >> > From what I recall - without Libre we see download bloat of 300ms or so. With Libre, it's gone. On waveform we see 0ms added bloat each direction for most clients.<br>
>>>> >><br>
>>>> >> The numbers report by speedtest bounce around a lot, and they tend to<br>
>>>> >> pick a lower number as a final result than I'd<br>
>>>> >> like. If there's a way to capture a movie of it...<br>
>>>> >> ><br>
>>>> >> > And I like the "monitor only" mode idea.<br>
>>>> >> > Perhaps we could create the HTB tree, but just not attach the CAKE qdisc?<br>
>>>> >> > Technically even HTB could reduce latency by itself on overloaded APs , so it wouldn't be true passive monitoring, but it would allow us to compare the before/after of CAKE while still having qdiscs we can point cpumap-pping to.<br>
>>>> >> ><br>
>>>> >> > Alternatively, maybe we could use eBPF PPing just for this passive monitoring period?<br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> > On Mon, Oct 24, 2022 at 8:02 AM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>>> >> >><br>
>>>> >> >> Are you looking for a shaped result? That'll show "whatever bandwidth<br>
>>>> >> >> is left on the sector" without Libre, and around the customer's paid-for<br>
>>>> >> >> target with Libre (hopefully!).<br>
>>>> >> >><br>
>>>> >> >> One thing Preseem does well is that their onboarding process includes<br>
>>>> >> >> "leave it in monitoring-only mode" for a week, gathering data before you<br>
>>>> >> >> pull the switch (although most ISPs I've talked to just pull the switch...)<br>
>>>> >> >> It's quite enlightening to see a before/after, even with only FQ_CODEL<br>
>>>> >> >> as the shaper.<br>
>>>> >> >><br>
>>>> >> >> We could probably do something similar with a "monitor only" mode that<br>
>>>> >> >> doesn't enable any queues (is there a TC equivalent to "dummy" on<br>
>>>> >> >> FreeBSD?).<br>
>>>> >> >><br>
>>>> >> >> On Mon, Oct 24, 2022 at 8:52 AM Dave Taht via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>>> >> >>><br>
>>>> >> >>> I am curious if anyone here has speedtest results with libreqos on and<br>
>>>> >> >>> off, and can send a screen shot?<br>
>>>> >> >>><br>
>>>> >> >>> --<br>
>>>> >> >>> This song goes out to all the folk that thought Stadia would work:<br>
>>>> >> >>> <a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
>>>> >> >>> Dave Täht CEO, TekLibre, LLC<br>
>>>> >> >>> _______________________________________________<br>
>>>> >> >>> LibreQoS mailing list<br>
>>>> >> >>> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>>> >> >>> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>>>> >> >><br>
>>>> >> >> _______________________________________________<br>
>>>> >> >> LibreQoS mailing list<br>
>>>> >> >> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>>> >> >> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> ><br>
>>>> >> > --<br>
>>>> >> > Robert Chacón<br>
>>>> >> > CEO | JackRabbit Wireless LLC<br>
>>>> >> > _______________________________________________<br>
>>>> >> > LibreQoS mailing list<br>
>>>> >> > <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>>> >> > <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >> --<br>
>>>> >> This song goes out to all the folk that thought Stadia would work:<br>
>>>> >> <a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
>>>> >> Dave Täht CEO, TekLibre, LLC<br>
>>>> >> _______________________________________________<br>
>>>> >> LibreQoS mailing list<br>
>>>> >> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>>> >> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> This song goes out to all the folk that thought Stadia would work:<br>
>>>> <a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
>>>> Dave Täht CEO, TekLibre, LLC<br>
>>><br>
>>> _______________________________________________<br>
>>> LibreQoS mailing list<br>
>>> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>><br>
>> _______________________________________________<br>
>> LibreQoS mailing list<br>
>> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
><br>
> _______________________________________________<br>
> LibreQoS mailing list<br>
> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
<br>
<br>
<br>
-- <br>
This song goes out to all the folk that thought Stadia would work:<br>
<a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
Dave Täht CEO, TekLibre, LLC<br>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr">Robert Chacón<br>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a><br></div></div>