From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 531032021DD for ; Fri, 24 Jan 2014 10:29:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D486E300D1; Fri, 24 Jan 2014 13:29:12 -0500 (EST) X-Virus-Scanned: OK Received: from app24.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B00D1300A7; Fri, 24 Jan 2014 13:29:12 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app24.wa-webapps.iad3a (Postfix) with ESMTP id 9EC8780055; Fri, 24 Jan 2014 13:29:12 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 24 Jan 2014 13:29:12 -0500 (EST) Date: Fri, 24 Jan 2014 13:29:12 -0500 (EST) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140124132912000000_56541" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1390588152.64884025@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] a new chipset and elsewhere a review of streamboost X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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: Fri, 24 Jan 2014 18:29:14 -0000 ------=_20140124132912000000_56541 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWhile I applaud "making wifi fast", I'd like to see some substantial eff= ort in moving away from (beyond) Wifi's inherent limits to dense scaling.= =0A =0AThat's what I'm working on in my personal wireless lab, with my own = funds, since it's actually a problem that does not get solved by either IEE= E 802 Standards (they are important after it's developed, but the propagati= on and sharing issues at the PHY level are not to be invented by a committe= e) or by incumbent-oriented vendors who need a near-term $Billion market to= justify an investment of their top talent.=0A =0ASo in sum: wouldn't it be= nicer to focus on "making more scalable dense mobile wireless"? WiFi is g= onna run into a wall pretty soon. And not because open local wireless has = to run into that wall.=0A =0AUntil we realize that CSMA was a good idea for= coax, but is not scalable in dense scattering propagation environments wit= h many, many users, we won't get there. Not with mesh (which is good for fi= xed wireless, but not mobile) and not with dynamic frequency or power manag= ement either.=0A =0A =0A=0A=0AOn Friday, January 24, 2014 8:15am, "Dave Tah= t" said:=0A=0A=0A=0A> On Fri, Jan 24, 2014 at 7:28 AM= , Maciej Soltysiak =0A> wrote:=0A> > Couldn't find a = mention of *codel, but it would be sad to see vendors=0A> > just sprinkle s= ome traffic shaping on top of codel and brand it.=0A> =0A> I'm perfectly ha= ppy qualcomm found a way to combine the packet=0A> classification technolog= y acquired from from bigfoot with the scheduling=0A> and aqm stuff given aw= ay here, in a business model that seems to be=0A> working. fq_codel made it= into wireless-backports because of them,=0A> and now we're seeing the down= stream effects when made easily available=0A> in the older kernels common i= n the embedded world, and when salesreps=0A> have something to push.=0A> = =0A> they also did up a nice gui. It's really neat they don't mention=0A> b= ufferbloat, ever, anywhere, and as a positive differentiator, that too,=0A>= appears to be working. That's sort of why I keep talking about=0A> the mak= e-wifi-fast concept as - as a mission - it has more positive=0A> connotatio= ns, than "if we don't fix bufferbloat the net's gonna die".=0A> =0A> ok, bl= oat fixes are being deployed everywhere along the edge.=0A> =0A> and everyb= ody wants to make-wifi-fast. some of the methods for doing so=0A> (wider ch= annels, louder radios) are more hurtful than the ones I'd=0A> like to see g= etting done, like:=0A> =0A> per station queues=0A> maximizing aggregation i= n txops=0A> multi-user mimo=0A> detecting interference=0A> eliminating reor= der buffers=0A> reducing retries=0A> reducing overly agressive attempts at = avoiding packet loss=0A> sorting on aggregate dequeue=0A> applying fq_codel= on a per station basis=0A> =0A> streamboost doesn't - as currently designe= d - apply to wifi. fq_codel=0A> only barely does at the layer of stack it's= in now, and these other factors=0A> predominate.=0A> =0A> > It cheers me u= p that *codel is about to be picked up by the vendors,=0A> > but not when c= ustomers are tricked to pay extra for SuperBoostNow [tm]=0A> > or DoMeQuick= [tm]...=0A> =0A> Well, there has been a lot of snake oil prior to now.=0A>= =0A> Hopefully the press will start creating more useful benchmarks.=0A> = =0A> I did bother to reply to that post. Me, I'd like benchmarks...=0A> =0A= > http://forums.smallnetbuilder.com/showthread.php?p=3D101052&posted=3D1#po= st101052=0A> =0A> one takeaway from that review was...=0A> =0A> the next jo= b facing us is to make-wifi-fast again, in increasingly crowded radio=0A> c= onditions, in a world where people insist on running HD video over it at th= e=0A> same time expecting decent videoconferencing and (at least my case) m= osh=0A> experiences....=0A> =0A> > --=0A> > Maciej=0A> >=0A> > On Fri, Jan = 24, 2014 at 1:06 PM, Aaron Wood wrote:=0A> >> It would = be interesting to see what streamboost gains on top of just=0A> >> fq_codel= . Since it appears that they are doing so fairly heavy-handed=0A> >> traff= ic shaping.=0A> >>=0A> >> -Aaron=0A> >>=0A> >>=0A> >> On Fri, Jan 24, 2014 = at 12:48 PM, Dave Taht =0A> wrote:=0A> >>>=0A> >>> An = interesting new chipset:=0A> >>>=0A> >>>=0A> >>>=0A> http://www.anandtech.c= om/show/7526/qualcomm-atheros-announces-new-internet-processor-lineup-ipq80= 64-and-ipq8062=0A> >>>=0A> >>> And streamboost (of which fq_codel is a comp= onent) is getting good=0A> >>> reviews:=0A> >>>=0A> >>>=0A> >>>=0A> http://= www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-streamb= oost-really-work?start=3D1=0A> >>>=0A> >>> --=0A> >>> Dave T=C3=A4ht=0A> >>= >=0A> >>> Fixing bufferbloat with cerowrt:=0A> >>> http://www.teklibre.com/= cerowrt/subscribe.html=0A> >>> ____________________________________________= ___=0A> >>> Cerowrt-devel mailing list=0A> >>> Cerowrt-devel@lists.bufferbl= oat.net=0A> >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> >>= =0A> >>=0A> >>=0A> >> _______________________________________________=0A> >= > Cerowrt-devel mailing list=0A> >> Cerowrt-devel@lists.bufferbloat.net=0A>= >> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> >>=0A> =0A> = =0A> =0A> --=0A> Dave T=C3=A4ht=0A> =0A> Fixing bufferbloat with cerowrt: h= ttp://www.teklibre.com/cerowrt/subscribe.html=0A> _________________________= ______________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lis= ts.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel= =0A> ------=_20140124132912000000_56541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

While I ap= plaud "making wifi fast", I'd like to see some substantial effort in moving= away from (beyond) Wifi's inherent limits to dense scaling.

=0A

 

=0A

That= 's what I'm working on in my personal wireless lab, with my own funds, sinc= e it's actually a problem that does not get solved by either IEEE 802 Stand= ards (they are important after it's developed, but the propagation and shar= ing issues at the PHY level are not to be invented by a committee) or by in= cumbent-oriented vendors who need a near-term $Billion market to justify an= investment of their top talent.

=0A

&nb= sp;

=0A

So in sum: wouldn't it be nicer = to focus on "making more scalable dense mobile wireless"?  WiFi is gon= na run into a wall pretty soon.  And not because open local wireless h= as to run into that wall.

=0A

 

= =0A

Until we realize that CSMA was a good i= dea for coax, but is not scalable in dense scattering propagation environme= nts with many, many users, we won't get there. Not with mesh (which is good= for fixed wireless, but not mobile) and not with dynamic frequency or powe= r management either.

=0A

 

=0A 

=0A=0A


=
On Friday, January 24, 2014 8:15am, "Dave Taht" <dave.taht@gmail.c= om> said:

=0A
=0A

> On Fri, Jan 24, 2014 at 7:28 AM, Maciej Solty= siak <maciej@soltysiak.com>
> wrote:
> > Couldn't = find a mention of *codel, but it would be sad to see vendors
> >= just sprinkle some traffic shaping on top of codel and brand it.
>=
> I'm perfectly happy qualcomm found a way to combine the packet<= br />> classification technology acquired from from bigfoot with the sch= eduling
> and aqm stuff given away here, in a business model that s= eems to be
> working. fq_codel made it into wireless-backports beca= use of them,
> and now we're seeing the downstream effects when mad= e easily available
> in the older kernels common in the embedded wo= rld, and when salesreps
> have something to push.
>
&= gt; they also did up a nice gui. It's really neat they don't mention
&= gt; bufferbloat, ever, anywhere, and as a positive differentiator, that too= ,
> appears to be working. That's sort of why I keep talking about<= br />> the make-wifi-fast concept as - as a mission - it has more positi= ve
> connotations, than "if we don't fix bufferbloat the net's gonn= a die".
>
> ok, bloat fixes are being deployed everywhere = along the edge.
>
> and everybody wants to make-wifi-fast.= some of the methods for doing so
> (wider channels, louder radios)= are more hurtful than the ones I'd
> like to see getting done, lik= e:
>
> per station queues
> maximizing aggregation= in txops
> multi-user mimo
> detecting interference
&= gt; eliminating reorder buffers
> reducing retries
> reduci= ng overly agressive attempts at avoiding packet loss
> sorting on a= ggregate dequeue
> applying fq_codel on a per station basis
&g= t;
> streamboost doesn't - as currently designed - apply to wifi. = fq_codel
> only barely does at the layer of stack it's in now, and = these other factors
> predominate.
>
> > It che= ers me up that *codel is about to be picked up by the vendors,
> &g= t; but not when customers are tricked to pay extra for SuperBoostNow [tm]> > or DoMeQuick [tm]...
>
> Well, there has bee= n a lot of snake oil prior to now.
>
> Hopefully the press= will start creating more useful benchmarks.
>
> I did bot= her to reply to that post. Me, I'd like benchmarks...
>
> = http://forums.smallnetbuilder.com/showthread.php?p=3D101052&posted=3D1#= post101052
>
> one takeaway from that review was...
&= gt;
> the next job facing us is to make-wifi-fast again, in increa= singly crowded radio
> conditions, in a world where people insist o= n running HD video over it at the
> same time expecting decent vide= oconferencing and (at least my case) mosh
> experiences....
&g= t;
> > --
> > Maciej
> >
> > O= n Fri, Jan 24, 2014 at 1:06 PM, Aaron Wood <woody77@gmail.com> wrote:=
> >> It would be interesting to see what streamboost gains o= n top of just
> >> fq_codel. Since it appears that they are = doing so fairly heavy-handed
> >> traffic shaping.
> = >>
> >> -Aaron
> >>
> >>> >> On Fri, Jan 24, 2014 at 12:48 PM, Dave Taht <dave.taht@= gmail.com>
> wrote:
> >>>
> >>>= ; An interesting new chipset:
> >>>
> >>>=
> >>>
> http://www.anandtech.com/show/7526/qualco= mm-atheros-announces-new-internet-processor-lineup-ipq8064-and-ipq8062
> >>>
> >>> And streamboost (of which fq_code= l is a component) is getting good
> >>> reviews:
>= >>>
> >>>
> >>>
> http:= //www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-strea= mboost-really-work?start=3D1
> >>>
> >>> = --
> >>> Dave T=C3=A4ht
> >>>
> &= gt;>> Fixing bufferbloat with cerowrt:
> >>> http://= www.teklibre.com/cerowrt/subscribe.html
> >>> ____________= ___________________________________
> >>> Cerowrt-devel ma= iling list
> >>> Cerowrt-devel@lists.bufferbloat.net
= > >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>
> >>
> >>
> >> ___= ____________________________________________
> >> Cerowrt-dev= el mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
&g= t; >>
>
>
>
> --
> Dave T= =C3=A4ht
>
> Fixing bufferbloat with cerowrt: http://www.t= eklibre.com/cerowrt/subscribe.html
> ______________________________= _________________
> Cerowrt-devel mailing list
> Cerowrt-de= vel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/= cerowrt-devel
>

=0A
 ------=_20140124132912000000_56541--