Re: [Rpm] Alternate definitions of "working condition" - unnecessary?

[Dave Taht <dave.taht@gmail.com>]

On Wed, Oct 6, 2021 at 12:11 PM Rich Brown via Rpm
<rpm@lists.bufferbloat.net> wrote:
>
> A portion of yesterday's RPM call encouraged people to come up with new definitions of "working conditions".
>
> This feels like a red herring.
>
> We already have two worst-case definitions - with implementations - of tools that "stuff up" a network. Flent and Apple's RPM Tool drive a network into worst-case behavior for long (> 60 seconds) and medium (~20 seconds) terms.
>
> What new information would another "working conditions" test expose that doesn't already come from Flent/RPM Tool? Thanks.

The specific case where it seemed needed was in testing wifi. A single
client test on most APs today does tend to blow up the
whole link, but doesn't on fq_codel derived ones, (Also, Meraki used
to use SFQ). Without two or more clients the result
can be misleading.

We had gone into the case where testing the latest 802.11ax DU
standards - where simultaneous transmssions to multiple clients were
feasible, but really hard to test for (As well as how to go about
designing a gang scheduler for the AP), and I'm also beginning to
worry
about the chaos with that standard for the ack return path.

There are also some cases (cake's per host/per flow fq) where perhaps
the test should bind to multiple ipv6 address.

There are additional cases where, perhaps, the fq component works, and
the aqm doesn't.

>
> Rich
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC