From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 683B33B2AF; Sun, 13 Mar 2016 14:19:08 -0400 (EDT) Received: by mail-oi0-x22a.google.com with SMTP id d205so118905881oia.0; Sun, 13 Mar 2016 11:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nFOAwWqYK5a8oGcXBvaNnzE2r/63k9cpZ2YJc+LS5vM=; b=iwdSipLIKH8KadERtd4/z5wFj9aOt7mrKQobPH/t/ItEUS+eme997tgo8EqV6IVqAG otJf+dpOm2lyOC0FbotAbVdjALETq1vUDIoBFAY0mQwwL1MCnb0uxiaxeUBzc4AZ4opM JdFoC6vtOjYxWvuDOPV2Rx78WqhP3Zn8sVMnbvyRKodoNl+QKmSWdXG+KciFupU2f9ul GM9Cm0Mar2/b4lCKzNYEx+gBH1fAorM/WA5DwCKVHdoro6WwoWIRFQktGaTgx8lV5/tp K32tfiiG40K9YKZTLLYpP/UpOdSjYiYEd7UFSsT1zjplP5ZcLjlN8Eoq8WTWqcLz3Woe p2bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nFOAwWqYK5a8oGcXBvaNnzE2r/63k9cpZ2YJc+LS5vM=; b=LQoIswd1Ks6r++nCNZ483Dk63MR3kJZc5l229US9vC44Bd58LwRPNVOfU7+t/l9JS6 pbaJhlv408IY1qsoLMEtql5C30TJE51bbV7CxZmws1rci3WFT1NL2zqO1QnEQif8pAVD LDAaFTzu0Z7DbPYEmRA70/ZqgLeLzndt9mXu6VwFeIl3BTte8ROyoSVjHziirpdOvFgz B4Uj1inr6UizK5sjIPlf5ZacQTnrHGJITCPgPlhNAhItTsIJ/dPVbB+NHzR5DUn15WOP Bnv9pavr70Xzt6CWqUEiNKJgAFv7OLMG6YUxbETC5no4TdIT/WRWr5xjdxOUDb8pJpZO aGww== X-Gm-Message-State: AD7BkJJKaFBgjS0vfB/E5QzHHvjfNbVQPXbSDko7wD2KZbDAiKWrwoGrr+hT+ZYLCRvldIDucFE68LbTy/kqmQ== MIME-Version: 1.0 X-Received: by 10.202.228.10 with SMTP id b10mr11172958oih.32.1457893147813; Sun, 13 Mar 2016 11:19:07 -0700 (PDT) Received: by 10.202.79.88 with HTTP; Sun, 13 Mar 2016 11:19:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Mar 2016 11:19:07 -0700 Message-ID: From: Dave Taht To: Adrian Chadd Cc: Henning Rogge , make-wifi-fast@lists.bufferbloat.net, bufferbloat-fcc-discuss , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 18:19:08 -0000 On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd wrote: > On 12 March 2016 at 11:14, Henning Rogge wrote: >> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman >> wrote: >>> I understand that Broadcom was paid to develop the Pi, a totally free board. >>> >>> And they already make wireless chipsets. >> >> The question is how easy would it be to build a modern 802.11ac >> halfmac chip... the amount of work these chips do (especially with 3*3 >> or 4*4 MIMO) is not trivial. > > It's not that scary - most of the latency sensitive things are: > > * channel change - eg background scans > * calibration related things - but most slow calibration could be done > via firmware commands, like the intel chips do! > * transmit a-mpdu / retransmit > * transmit rate control adaptation > * receiving / block-ack things - which is mostly done in hardware anyway > * likely some power save transition-y things too > > If you're doing STA mode, then you have more things to do - eg bgscans > with active traffic, TDLS, P2P, etc. > If you're doing hostap mode or heck, even mostly-dumb ibss mode - > where there's no requirement for off-channel traffic - the firmware is > mostly just a transmit/receive engine and some power save stuff. > > And honestly - know how many cycles a modern CPU has? If you don't > care about hyper-optimising for power consumption (ie, you're not a > phone), then I bet you could get away with ath9k model hardware. Those > same lower end CPUs can do 200kpps on an ethernet NIC right now. The > reordering and retransmit stuff could be handled in firmware, but > that's about it - and again, only if you wanted to do it on some > anenmic SoC or you cared about power. It is not always "cycles" as context switch latency - which is often mitigated (now) by having general purpose multi-core hardware available, but still hard to get into the us range reliably enough. That said, doing 802.11ac right requires a LOT of on-board DSP processing, and the design of the first chips out the door pre-dated the arrival of modern multi-cores. I certainly think that everything we laid out to improve wifi in make-wifi-fast is now doable on nearly all now-shipping processors and on the ath9k - and work is also proceeding on non-open-source versions of the ideas in iwl and in the next gen ath10k based products. Lots of discussion on the linux-wireless mailing list and patches landing. I do, very much, want to avoid the separate baseband processor that inhabits most cell designs and retain the core smarts for wifi in general purpose processors. Getting locked into a celluar patent and binary blob model would be a bad thing. > > People keep talking about "oh god, these things do so much now" - but > that's because people are thinking about phones or those L2-cache-less > anemic older SOCs that are massively memory bandwidth constrained. > Newer stuff is much less terrible. The ath9k has a long life in it yet, particularly at 2.4ghz, agreed. Yet, I look at the new pi, and see a broadcom chip and driver that could be improved much. I see dozens of other wifi chips that could use more software and design effort, and more coming down the pike. And I gotta admit that 802.11ac, even in it's current state, is now superior to 802.11n in nearly every way, except for the shoddy state of the usually binary-only firmware. Which has got a lot better over the past year. I can see - just as it happened to modems - more soft-mac-is wifi chips arriving like the mt72 - or approaches that load the entire stack on an ethernet-like interface. What I don't see is enough students and engineers with sufficient background in how wifi really works available to handle the billions of devices yet to be shipped. I'd like to attach a knowledge vacuum to your brain, adrian, for example.... One of the things obscured by the "whole router lockdown" debate here is that the binary blob problem is most acute on the next-gen 802.11ac chips (well, also acute on the video drivers). Anybody using those blobs can certainly not lock down the entire router, and ship a blob for the wifi. Which is historically what has always happened here - the ath9k being the sole exception. Blobs are a PITA in themselves. At one positive note, I think usb-wifi interfaces are going to go the way of the dodo, and be replaced almost entirely by on-board interfaces, for which I hope for a blob-free outcome on at least one design. > > > > -adrian > _______________________________________________ > bufferbloat-fcc-discuss mailing list > bufferbloat-fcc-discuss@lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss