From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3E2043B2BD; Sun, 13 Mar 2016 21:25:39 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u2E1PSou030287; Sun, 13 Mar 2016 17:25:28 -0800 Date: Sun, 13 Mar 2016 18:25:28 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Adrian Chadd cc: bufferbloat-fcc-discuss , cerowrt-devel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net, Henning Rogge In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 01:25:39 -0000 On Sun, 13 Mar 2016, Adrian Chadd wrote: > You do that in hardware. Do the Mac, phy and RF in hardware. > > This is what the qca hardware does. unfortunantly, that's not what the existing chipsets do. So unless you can create a new chipset, you can't just change what's done in hardware. David Lang > a > On Mar 13, 2016 5:25 PM, "David Lang" wrote: > >> On Sat, 12 Mar 2016, 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 >>> >> >> you are ignoring MU-MIMO, the ability to transmit different signals from >> each antenna so that the interference patterns from the different signals >> result in different readable data depending on where the receiver is in >> relation to the access point is not a trivial thing. >> >> But it's one of the most valuable features in the spec. >> >> David Lang >> >