From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 173EA3B29E for ; Mon, 24 Oct 2022 17:57:26 -0400 (EDT) Received: by mail-wr1-x434.google.com with SMTP id bu30so18134948wrb.8 for ; Mon, 24 Oct 2022 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MM3GE96vkBxLVK+f100k59jPtqygyUm3jsQcB+lVfDw=; b=myx6fQZkslKGJy7EixlU8EXFMem2tAD3792tK8enR4SitlZC9THuRul/R41TpV+Ei0 WjJ3nZzNDmGoO37Gk/jCyYFwZ3oXNiCjLpMaDyHtPMAHcfzSm98/0xsBIxMWfPHqXoQU B3mLnS58UzyvzEY9erJOzaWVod9b+etvcHLMivhteaZtZRloJNFuCpETkoU2L3Qbbejb bTZeWrkSaJ6Cesg+u1NtgX70T/d+SwLey8K0qrUz4iTP3xN2jnPk9D6F/uK5O1+cA5Zv lBUqmGcYp2y45wJS7aFS8vXdQXXfAeIWsLe2Elpr4oxn3O1dcmmqXG/7BrIvJyL6SShZ HNzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MM3GE96vkBxLVK+f100k59jPtqygyUm3jsQcB+lVfDw=; b=o2VYtqRkz7cS5f+FtRrw6QVsy4IvV3BrCtJGi4ouFfk+gJw30ESoxSSyQwKwX2TY09 EAS3Za7bDs92QJju2YWU0wSO/sJ6aJFOBgBEvE2fRzFprMNKzOpMx05YI2auN+O77HNj CGyayCDn1Q5JSXccBdnBuK9ht+iGkKOkdiLu9DZZwvCPly115X1c++OCZ6U9Ba2Sf+l9 JnklrQfwo5R6Yj4PjGlzuqLcuFvKvx2MI9K1hW5V0wGPgf1SWqCCmC+zogmX4SozBqtV EuWfkonQ9tbDFGrBghrnpgFDQW6f8DGDVE5KWoW2ZduKOBDtq1zJgeCNagoR4+ID4Lsi Pq+w== X-Gm-Message-State: ACrzQf1u60iRbjtzah0elgf7tbsoKto8AjTZQm22AGBVn9ajaRN6pEnd BkQnHfVIxsyI6b9saqSyJTc3/wNjzq1F1W7csB4= X-Google-Smtp-Source: AMsMyM5hLikaZroocg733TBOK9YdKBXjubx2RqCwd1ZZ6Mvd52h96ChkoPCiyW1tjfLKe6KOBA2LTEDXF5AAi7ksZcU= X-Received: by 2002:a5d:47a1:0:b0:236:6f4d:1db3 with SMTP id 1-20020a5d47a1000000b002366f4d1db3mr5443295wrb.383.1666648645857; Mon, 24 Oct 2022 14:57:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 24 Oct 2022 14:57:13 -0700 Message-ID: To: Herbert Wolverson Cc: libreqos@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [LibreQoS] Ack-filtering X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2022 21:57:27 -0000 On Mon, Oct 24, 2022 at 2:19 PM Herbert Wolverson via LibreQoS wrote: > > Highly un-scientific (we need to let it run for a bit and do a proper bef= ore-after comparison that includes a decent timeframe), but I like the quic= k'n'dirty results of testing "ack-filter": > > We've been having a Bad Network Day (TM), with sudden flooding making us = use some pretty constrained I've been looking at various ddos mitigation schemes of late. Are you using= any? >- so our latencies were really suffering in one region. That region just h= appens to be the worst part of our network (we haven't finished digesting a= n acquisition; there's even Bullet M2 omnis up there!). Lots of relatively = low-speed plans, all with big variance (10/3, 25/5, I found a 5/1 that some= one forgot to upgrade!). They seem to have benefitted greatly. The parts of= the network that were doing great - are still doing great, with very littl= e change. I made my previous comments in looking at the swing downwards being so large, possibly not being a positive direction (my ever suspicious gut was reacting, but I wasn't qualifying the numbers - been a long day here too) I also forgot to mention that ack-filtering uses up less txops on older versions of wifi. Very useful. I'd meant to put it into my mt76 stuff ages ago but got overwhelmed by bugs. > Just a quick'n'dirty test. I'll try and put something more useful togethe= r tomorrow, when it's had a chance to see how peak time hits it. :crossed fingers: > > (Also, this digging revealed an issue with pping-cpumap in production. It= wasn't tracking enough flows, so the reporting is heavily biased towards t= he top-consumers - who are likely to be monitored before the buffer fills u= p and it stops counting until stats are read. So I added a "maximums.h" fil= e to make it easy to set user limits, and made flow-count derive from that.= ) I think polling it more frequently would be closer to the typical durations of flows. Most flows last for under 3 seconds. What would be the harm in vastly expanding the number of flows it tracks? /me hides > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC