From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 48E563CB46; Tue, 6 Jul 2021 22:26:59 -0400 (EDT) Received: by mail-io1-xd36.google.com with SMTP id g22so1180125iom.1; Tue, 06 Jul 2021 19:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9AZUm6tWi5/nTm9tqr3v2WpclxIzB0fRyMIUuaYjeXU=; b=Bq/fHWLJ/4yywPWUi66medFJ25hJz5pQJPqYATzIxMaR3xDEVDMKKlFlbLcVpWpQ0r Jijs0bQjTGFcw75HkvZ+mxf0fD0W+VuIzyZJZCubmZJZCfb1eHzfa2Lcz/qZMV2XVIvI 3i57vno+pCuhpTR41ogmVs2cK+IWlkJK7igSgn27pfBDbJ8SOs/nLllhNSDoz1WM143l 9lIqpCXjDWQqrxt3psMlWO1j1UPyfEUfUhyb4nWSMnjZg3caZYeT6+I8zQv6qSWnZFWw gbNNg9VMzNnpoDwpKSFWoIe6bN4LN2kGOFa7NBN7UT/fDGkKWoUF9W3cYvRYEQXXbJAa jRJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9AZUm6tWi5/nTm9tqr3v2WpclxIzB0fRyMIUuaYjeXU=; b=HzoW2htnP8v3/fBT2pz9H/EtGzchFnVWbPaTka8ZfLinDBJO/TNEVAsP6UJKg/2Y6a RBagfllnwQhuHq2/9JuDh8shnJ53uIL4dsOvi0KZls/N4jLI4TUxPswrkEyHthxDmFIA PfgAUcj4ttKcww+x1+SeVBrQwgrHmf+WJ0xJjhulnV4CBet375Q+LB8bbfeL2eucSU3e vU1Z+8gVIGgxMBWMY04L8gRpaEciErENazew4O74BrNs7z2G5vkKa36HCUQn7SUwDmpu ida5XT1t6ALsLTG6bxRdKbCf36mSTge1nOJK4IS89lN81nFW3G12zHGBsoHjSdqKcd4S 7Jig== X-Gm-Message-State: AOAM532SapQvY3Zp/KLkAnN2HFyPqgPbOoqv4I44Rk5u4cEk0p38O5xR oWEGTDYmDmoENqXukatiHpASCXvBDHmWAwb7Tuo= X-Google-Smtp-Source: ABdhPJyIGPxB73/li3Wau7hJ86+5NRZTG/RvIrdpXeqT+6L/bcgBIvMYqhkHIKlgFb/cMjt8IP8M/IKGkoCZPkI3fb8= X-Received: by 2002:a05:6602:71c:: with SMTP id f28mr3569106iox.161.1625624818537; Tue, 06 Jul 2021 19:26:58 -0700 (PDT) MIME-Version: 1.0 References: <20210621210048.628befdb@hermes.local> <38CC4C4D-AE42-4629-8472-16BCC0DEAFEA@gmx.de> <2dbdf457-5652-6b74-7014-3bf79dde6bc9@gmx.com> In-Reply-To: From: Dave Taht Date: Tue, 6 Jul 2021 19:26:47 -0700 Message-ID: To: Aaron Wood Cc: Giuseppe De Luca , bloat , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [Bloat] Really getting 1G out of ISP? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 02:26:59 -0000 On Tue, Jul 6, 2021 at 3:32 PM Aaron Wood wrote: > > I'm running an Odyssey from Seeed Studios (celeron J4125 with dual i211),= and it can handle Cake at 1Gbps on a single core (which it needs to, becau= se OpenWRT's i211 support still has multiple receive queues disabled). Not clear if that is shaped or not? Line rate is easy on processors of that class or better, but shaped? some points: On inbound shaping especially it it still best to lock network traffic to a single core in low end platforms. Cake itself is not multicore, although the design essentially is. We did some work towards trying to make it shape across multiple cores and multiple hardware queues. IF the locking contention could be minimized (RCU) I felt it possible for a win here, but a bigger win would be to eliminate "mirred" from the ingress path entirely. Even multiple transmit queues remains kind of dicy in linux, and actually tend to slow network processing in most cases I've tried at gbit line rates. They also add latency, as (1) BQL is MIAD, not AIMD, so it stays "stuck" at a "good" level for a long time, AND 2) each hw queue gets an additive fifo at this layer, so where, you might need only 40k to keep a single hw queue busy, you end up with 160k with 4 hw queues. This problem is getting worse and worse (64 queues are common in newer hardware, 1000s in really new hardware) and a revisit to how BQL does things in this case would be useful. Ideally it would share state (with a cross core variable and atomic locks) as to how much total buffering was actually needed "down there" across all the queues, but without trying it, I worry that that would end up costing a lot of cpu cycles. Feel free to experiment with multiple transmit queues locked to other cores with the set-affinity bits in /proc/interrupts. I'm sure these MUST be useful on some platform, but I think most of the use for multiple hw queues is when a locally processing application is getting the data, not when it is being routed. Ironically, I guess, the shorter your queues the higher likelihood a given packet will remain in l2 or even l1 cache. I > > On Tue, Jun 22, 2021 at 12:44 AM Giuseppe De Luca w= rote: >> >> Also a PC Engines APU4 will do the job >> (https://inonius.net/results/?userId=3D17996087f5e8 - this is a >> 1gbit/1gbit, with Openwrt/sqm-scripts set to 900/900. ISP is Sony NURO >> in Japan). Will follow this thread to know if some interesting device >> popup :) >> >> >> https://inonius.net/results/?userId=3D17996087f5e8 >> >> On 6/22/2021 6:12 AM, Sebastian Moeller wrote: >> > >> > On 22 June 2021 06:00:48 CEST, Stephen Hemminger wrote: >> >> Is there any consumer hardware that can actually keep up and do AQM a= t >> >> 1Gbit. >> > Over in the OpenWrt forums the same question pops up routinel= y once per week. The best answer ATM seems to be a combination of a raspber= ry pi4B with a decent USB3 gigabit ethernet dongle, a managed switch and an= y capable (OpenWrt) AP of the user's liking. With 4 arm A72 cores the will = traffic shape up to a gigabit as reported by multiple users. >> > >> > >> >> It seems everyone seems obsessed with gamer Wifi 6. But can only do >> >> 300Mbit single >> >> stream with any kind of QoS. >> > IIUC most commercial home routers/APs bet on offload engines to do mos= t of the heavy lifting, but as far as I understand only the NSS cores have = a shaper and fq_codel module.... >> > >> > >> >> It doesn't help that all the local ISP's claim 10Mbit upload even wit= h >> >> 1G download. >> >> Is this a head end provisioning problem or related to Docsis 3.0 (or >> >> later) modems? >> > For DOCSIS the issue seems to be an unfortunate frequency split betwee= n up and downstream and use of lower efficiency coding schemes . >> > Over here the incumbent cable isp provisions fifty Mbps for upstream = and plans to increase that to hundred once the upstream is switched to docs= is 3.1. >> > I believe one issue is that since most of the upstream is required for= the reverse ACK traffic for the download and hence it can not be oversubsc= ribed too much.... but I think we have real docsis experts on the list, so = I will stop my speculation here... >> > >> > Regards >> > Sebastian >> > >> > >> > >> > >> >> _______________________________________________ >> >> Bloat mailing list >> >> Bloat@lists.bufferbloat.net >> >> https://lists.bufferbloat.net/listinfo/bloat >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC