On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd <adr...@freebsd.org> wrote: > On 12 March 2016 at 11:14, Henning Rogge <hro...@gmail.com> wrote: >> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman >> <wayne.workman2...@gmail.com> 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-disc...@lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel