From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A893F3B29D for ; Wed, 6 Oct 2021 17:22:27 -0400 (EDT) Received: by mail-il1-x136.google.com with SMTP id j2so4241688ilo.10 for ; Wed, 06 Oct 2021 14:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BBR0lmcDUKuVJfYUJ7kn910maE0+nck9k4RdotRGipQ=; b=Op+P9wc+ego0dCP5gWNFGKEJTfRNqVpOYMu0aOSsOnDPRS55285BRaBuF5L41mlj+C kDH00AdbL94W30Fyb+a6lBHAE+/QTbkM8raWg1k0KiWWQzMMRZTD2SgDASD92jxC9qVp 85dfp5PeiT5MwTSN+kehhlcowTmrrkdaQlep/rA2OILNQ6pO+FswTY/+POBkG8IsAuC9 Jh6jYWOV9laQhdYRa6TFnCNCSkV9ayciZj03C2WMijqbsu1EcBDTUsO3jqwLNqRbAPC/ PFcWmsSDAFouajI7RvrwRR2bqNrQ0hAkBOQ7gXPu0foQHWB24iy20XVtMnsRW90pZI0W KZfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BBR0lmcDUKuVJfYUJ7kn910maE0+nck9k4RdotRGipQ=; b=xPaD2B8mEvs3Lywl2aelQbV//KdPBpoiBwFMOz3aGKn8gg8lsk/hDICTkDcU15MxH6 xPvIPWLNLHSs3jQPY+FVsJFMdAr7M1ucxn2ILi7wNYWHxa5qEKrltais61y708x2ff1J msnlGSu33J/alJSPm+kZNMTFbZ0LKkAFXQIx5WCUvwEMCOjZQApweqzYGy0hdyTPHZsk 5TkIpppfZ5mPtr+PW7+k1XcWqIwmIayK9MyHUa1/j0UVZgFuqfMl1iL3Ro0EJhimsgGI cBYRud2I/gVZsvytoDbSLlg/h85Yd0VrY0XEvqkTFPCSKBJnFHxZ5MOB4fBW8+e2X2/N 8GnQ== X-Gm-Message-State: AOAM531ozgszWtQLe2YdUb6XutDhv25wVWIAJjkN389cxO0gplbKdZeo my3TxniKa4R98zj+nYX5C87NfYIy3zIVBwwx6KcdEUql X-Google-Smtp-Source: ABdhPJzxF/9dw6k+YdrOkDBswOItlpZ5Nfo58OofKJr+Fd2kEmfPQpY07XvdRx4U6vAgjH1h8QckJXMselzDpa60NkI= X-Received: by 2002:a05:6e02:168f:: with SMTP id f15mr300007ila.283.1633555346997; Wed, 06 Oct 2021 14:22:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 6 Oct 2021 14:22:15 -0700 Message-ID: To: Rich Brown Cc: Rpm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Rpm] Alternate definitions of "working condition" - unnecessary? X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 21:22:27 -0000 On Wed, Oct 6, 2021 at 12:11 PM Rich Brown via Rpm wrote: > > A portion of yesterday's RPM call encouraged people to come up with new d= efinitions of "working conditions". > > This feels like a red herring. > > We already have two worst-case definitions - with implementations - of to= ols that "stuff up" a network. Flent and Apple's RPM Tool drive a network i= nto worst-case behavior for long (> 60 seconds) and medium (~20 seconds) te= rms. > > 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 --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC