[Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Dave Taht]

On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> On 12 March 2016 at 11:14, Henning Rogge <hrogge at gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> <wayne.workman2012 at 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-discuss at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss