From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1E0C72021DD for ; Fri, 24 Jan 2014 15:54:27 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id tp5so3526190ieb.5 for ; Fri, 24 Jan 2014 15:54:26 -0800 (PST) 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:content-type:content-transfer-encoding; bh=d2J8sJlHNDnXQOD7wnesn6/85MODQvliYXXrjfPmCi0=; b=A8T1Gavdn0slQs4dHnL3Sh+It7PXLbnAUBkSjvd7YGbUBmkCiOSpVbXqsNv7l2Ti+M ZgPWiwRt2hG4Ow5sylA0vvwtQPjcKN1Cp2a7M9YzlEeX+ml3fcFWHJAyiIXiXr3I9Gsg kNqB7nySXUREoPFuZHhiK6mu32JU4gQro6xyqWRHSy+nnZV3uvkOJme3m09cf6MXW3qp 0A78NGMONnkLFjmn6kEyXpfy/zCD/BRpN9p8DdgCmK7SqwlFdo5jqCUbXxe//Gxx0lKn zs0On9Ns/BKzG+PqgeSZxH0ux/RPC9WuLRN/IwE2slepf5Pnyzw+QeZarEucW5Om4Hw+ /WMw== MIME-Version: 1.0 X-Received: by 10.50.154.102 with SMTP id vn6mr7068007igb.1.1390607666206; Fri, 24 Jan 2014 15:54:26 -0800 (PST) Received: by 10.64.145.67 with HTTP; Fri, 24 Jan 2014 15:54:26 -0800 (PST) In-Reply-To: <1390588152.64884025@apps.rackspace.com> References: <1390588152.64884025@apps.rackspace.com> Date: Fri, 24 Jan 2014 18:54:26 -0500 Message-ID: From: Dave Taht To: David Reed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 23:54:27 -0000 On Fri, Jan 24, 2014 at 1:29 PM, wrote: > While I applaud "making wifi fast", I'd like to see some substantial effo= rt > in moving away from (beyond) Wifi's inherent limits to dense scaling. I agree. So much of what's wrong with wifi comes down to that. > That'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 IEEE 802 > Standards (they are important after it's developed, but the propagation a= nd > sharing issues at the PHY level are not to be invented by a committee) or= by > incumbent-oriented vendors who need a near-term $Billion market to justif= y > an investment of their top talent. If I could fund you, I would. The promise of what you have described to me is great; a worldchanger. A problem is that it will take years of tinkering= to get it right... but it is also nice that what took supercomputers in the 90= s to calculate now can run on your phone. in terms of doing experimentation with available hardware... I continue to follow developments at aptiva with great interest. http://www.adapteva.com/news/carmel-ventures-and-ericsson-invest-in-adaptev= a/ that chip and fpga have what might be enough oomph to do the DSP needed. I've had my own cluster on order for quite some time now. I would like very much to be "in" on the design of a new wireless chip, but to me I'd want to create one that existed within existing standards first... > So in sum: wouldn't it be nicer to focus on "making more scalable dense > mobile wireless"? WiFi is gonna run into a wall pretty soon. And not > because open local wireless has to run into that wall. I think 802.11ak has some potential to dig us out of the hole, but not a lo= t, and that 802.11ac is close to the end of the road for the current framing formats. another problem is that one of the few target markets left is offplanet, ou= tside of the range of the FCC. > Until we realize that CSMA was a good idea for coax, but is not scalable = in > dense scattering propagation environments with many, many users, we won't > get there. Not with mesh (which is good for fixed wireless, but not mobil= e) > and not with dynamic frequency or power management either. People are only slowly waking up to the fact that the four color theorem only solves for a planar universe. > > > > On Friday, January 24, 2014 8:15am, "Dave Taht" sai= d: > >> On Fri, Jan 24, 2014 at 7:28 AM, Maciej Soltysiak >> 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 >> classification technology acquired from from bigfoot with the scheduling >> and aqm stuff given away here, in a business model that seems to be >> working. fq_codel made it into wireless-backports because of them, >> and now we're seeing the downstream effects when made easily available >> in the older kernels common in the embedded world, and when salesreps >> have something to push. >> >> they also did up a nice gui. It's really neat they don't mention >> bufferbloat, ever, anywhere, and as a positive differentiator, that too, >> appears to be working. That's sort of why I keep talking about >> the make-wifi-fast concept as - as a mission - it has more positive >> connotations, than "if we don't fix bufferbloat the net's gonna 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, like: >> >> per station queues >> maximizing aggregation in txops >> multi-user mimo >> detecting interference >> eliminating reorder buffers >> reducing retries >> reducing overly agressive attempts at avoiding packet loss >> sorting on aggregate dequeue >> applying fq_codel on a per station basis >> >> 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 cheers me up that *codel is about to be picked up by the vendors, >> > but not when customers are tricked to pay extra for SuperBoostNow [tm] >> > or DoMeQuick [tm]... >> >> Well, there has been a lot of snake oil prior to now. >> >> Hopefully the press will start creating more useful benchmarks. >> >> I did bother to reply to that post. Me, I'd like benchmarks... >> >> >> http://forums.smallnetbuilder.com/showthread.php?p=3D101052&posted=3D1#p= ost101052 >> >> one takeaway from that review was... >> >> the next job facing us is to make-wifi-fast again, in increasingly crowd= ed >> radio >> conditions, in a world where people insist on running HD video over it a= t >> the >> same time expecting decent videoconferencing and (at least my case) mosh >> experiences.... >> >> > -- >> > Maciej >> > >> > On Fri, Jan 24, 2014 at 1:06 PM, Aaron Wood wrote: >> >> It would be interesting to see what streamboost gains on 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 >> wrote: >> >>> >> >>> An interesting new chipset: >> >>> >> >>> >> >>> >> >> http://www.anandtech.com/show/7526/qualcomm-atheros-announces-new-intern= et-processor-lineup-ipq8064-and-ipq8062 >> >>> >> >>> And streamboost (of which fq_codel is a component) is getting good >> >>> reviews: >> >>> >> >>> >> >>> >> >> http://www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcom= ms-streamboost-really-work?start=3D1 >> >>> >> >>> -- >> >>> Dave T=E4ht >> >>> >> >>> Fixing bufferbloat with cerowrt: >> >>> http://www.teklibre.com/cerowrt/subscribe.html >> >>> _______________________________________________ >> >>> Cerowrt-devel mailing list >> >>> Cerowrt-devel@lists.bufferbloat.net >> >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> >> >> >> >> _______________________________________________ >> >> Cerowrt-devel mailing list >> >> Cerowrt-devel@lists.bufferbloat.net >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> >> >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html