[LibreQoS] ookla speedtest results?

[dan]

we also have a bunch of 25/5.  It would be nice to get some more detailed
numbers from ookla tests.  We also have a lot of Eero units out there, so
watching for the eero speed test would also be great.

On Mon, Oct 24, 2022 at 10:31 AM Herbert Wolverson via LibreQoS <
libreqos at lists.bufferbloat.net> wrote:

> > sniff DNS for those speed test lookups and trigger a packet capture for
> x duration?
>
> That's a good idea (I think there's a service somewhere for finding
> speedtest
> servers?). We're discussing testing the ack-filter feature right now, and
> something
> similar would work well for that. (We have a bunch of 25/5 and similarly
> asymmetric
> connections, in theory it'll help...)
>
> On Mon, Oct 24, 2022 at 10:31 AM dan via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
>
>> sniff DNS for those speed test lookups and trigger a packet capture for x
>> duration?
>>
>> On Mon, Oct 24, 2022 at 9:27 AM Dave Taht <dave.taht at gmail.com> wrote:
>>
>>> On Mon, Oct 24, 2022 at 8:20 AM dan <dandenson at gmail.com> wrote:
>>> >
>>> > Dave, I think that 'bouncing' is more CPU time in the browser.  I
>>> don't think it's indicative over what's actually happening.
>>>
>>> A simultaneous packet capture and wireshark plot of the RTTs would
>>> also be helpful.
>>>
>>> >
>>> > On Mon, Oct 24, 2022 at 9:09 AM Dave Taht via LibreQoS <
>>> libreqos at lists.bufferbloat.net> wrote:
>>> >>
>>> >> On Mon, Oct 24, 2022 at 8:02 AM Robert Chacón via LibreQoS
>>> >> <libreqos at lists.bufferbloat.net> wrote:
>>> >> >
>>> >> > I can run an Ookla test in the middle of the night with LibreQoS
>>> off for a bit.
>>> >>
>>> >> Groovy.
>>> >>
>>> >> > 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.
>>> >>
>>> >> The numbers report by speedtest bounce around a lot, and they tend to
>>> >> pick a lower number as a final result than I'd
>>> >> like. If there's a way to capture a movie of it...
>>> >> >
>>> >> > And I like the "monitor only" mode idea.
>>> >> > Perhaps we could create the HTB tree, but just not attach the CAKE
>>> qdisc?
>>> >> > 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.
>>> >> >
>>> >> > Alternatively, maybe we could use eBPF PPing just for this passive
>>> monitoring period?
>>> >> >
>>> >> >
>>> >> > On Mon, Oct 24, 2022 at 8:02 AM Herbert Wolverson via LibreQoS <
>>> libreqos at lists.bufferbloat.net> wrote:
>>> >> >>
>>> >> >> Are you looking for a shaped result? That'll show "whatever
>>> bandwidth
>>> >> >> is left on the sector" without Libre, and around the customer's
>>> paid-for
>>> >> >> target with Libre (hopefully!).
>>> >> >>
>>> >> >> One thing Preseem does well is that their onboarding process
>>> includes
>>> >> >> "leave it in monitoring-only mode" for a week, gathering data
>>> before you
>>> >> >> pull the switch (although most ISPs I've talked to just pull the
>>> switch...)
>>> >> >> It's quite enlightening to see a before/after, even with only
>>> FQ_CODEL
>>> >> >> as the shaper.
>>> >> >>
>>> >> >> We could probably do something similar with a "monitor only" mode
>>> that
>>> >> >> doesn't enable any queues (is there a TC equivalent to "dummy" on
>>> >> >> FreeBSD?).
>>> >> >>
>>> >> >> On Mon, Oct 24, 2022 at 8:52 AM Dave Taht via LibreQoS <
>>> libreqos at lists.bufferbloat.net> wrote:
>>> >> >>>
>>> >> >>> I am curious if anyone here has speedtest results with libreqos
>>> on and
>>> >> >>> off, and can send a screen shot?
>>> >> >>>
>>> >> >>> --
>>> >> >>> This song goes out to all the folk that thought Stadia would work:
>>> >> >>>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>> >> >>> Dave Täht CEO, TekLibre, LLC
>>> >> >>> _______________________________________________
>>> >> >>> LibreQoS mailing list
>>> >> >>> LibreQoS at lists.bufferbloat.net
>>> >> >>> https://lists.bufferbloat.net/listinfo/libreqos
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> LibreQoS mailing list
>>> >> >> LibreQoS at lists.bufferbloat.net
>>> >> >> https://lists.bufferbloat.net/listinfo/libreqos
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Robert Chacón
>>> >> > CEO | JackRabbit Wireless LLC
>>> >> > _______________________________________________
>>> >> > LibreQoS mailing list
>>> >> > LibreQoS at lists.bufferbloat.net
>>> >> > https://lists.bufferbloat.net/listinfo/libreqos
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> This song goes out to all the folk that thought Stadia would work:
>>> >>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>> >> Dave Täht CEO, TekLibre, LLC
>>> >> _______________________________________________
>>> >> LibreQoS mailing list
>>> >> LibreQoS at lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/libreqos
>>>
>>>
>>>
>>> --
>>> This song goes out to all the folk that thought Stadia would work:
>>>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>>> Dave Täht CEO, TekLibre, LLC
>>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221024/bebeec52/attachment-0001.html>