<font face="arial" size="2"><p style="margin:0;padding:0;">While I applaud "making wifi fast", I'd like to see some substantial effort in moving away from (beyond) Wifi's inherent limits to dense scaling.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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 and 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 justify an investment of their top talent.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">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 mobile) and not with dynamic frequency or power management either.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<!--WM_COMPOSE_SIGNATURE_START--><!--WM_COMPOSE_SIGNATURE_END-->
<p style="margin:0;padding:0;"><br /><br />On Friday, January 24, 2014 8:15am, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1390587471">
<p style="margin:0;padding:0;">> On Fri, Jan 24, 2014 at 7:28 AM, Maciej Soltysiak <maciej@soltysiak.com><br />> wrote:<br />> > Couldn't find a mention of *codel, but it would be sad to see vendors<br />> > just sprinkle some traffic shaping on top of codel and brand it.<br />> <br />> I'm perfectly happy qualcomm found a way to combine the packet<br />> classification technology acquired from from bigfoot with the scheduling<br />> and aqm stuff given away here, in a business model that seems to be<br />> working. fq_codel made it into wireless-backports because of them,<br />> and now we're seeing the downstream effects when made easily available<br />> in the older kernels common in the embedded world, and when salesreps<br />> have something to push.<br />> <br />> they also did up a nice gui. It's really neat they don't mention<br />> bufferbloat, ever, anywhere, and as a positive differentiator, that too,<br />> 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 positive<br />> connotations, than "if we don't fix bufferbloat the net's gonna die".<br />> <br />> ok, bloat fixes are being deployed everywhere along the edge.<br />> <br />> and everybody wants to make-wifi-fast. some of the methods for doing so<br />> (wider channels, louder radios) are more hurtful than the ones I'd<br />> like to see getting done, like:<br />> <br />> per station queues<br />> maximizing aggregation in txops<br />> multi-user mimo<br />> detecting interference<br />> eliminating reorder buffers<br />> reducing retries<br />> reducing overly agressive attempts at avoiding packet loss<br />> sorting on aggregate dequeue<br />> applying fq_codel on a per station basis<br />> <br />> streamboost doesn't - as currently designed - apply to wifi. fq_codel<br />> only barely does at the layer of stack it's in now, and these other factors<br />> predominate.<br />> <br />> > It cheers me up that *codel is about to be picked up by the vendors,<br />> > but not when customers are tricked to pay extra for SuperBoostNow [tm]<br />> > or DoMeQuick [tm]...<br />> <br />> Well, there has been a lot of snake oil prior to now.<br />> <br />> Hopefully the press will start creating more useful benchmarks.<br />> <br />> I did bother to reply to that post. Me, I'd like benchmarks...<br />> <br />> http://forums.smallnetbuilder.com/showthread.php?p=101052&posted=1#post101052<br />> <br />> one takeaway from that review was...<br />> <br />> the next job facing us is to make-wifi-fast again, in increasingly crowded radio<br />> conditions, in a world where people insist on running HD video over it at the<br />> same time expecting decent videoconferencing and (at least my case) mosh<br />> experiences....<br />> <br />> > --<br />> > Maciej<br />> ><br />> > On Fri, Jan 24, 2014 at 1:06 PM, Aaron Wood <woody77@gmail.com> wrote:<br />> >> It would be interesting to see what streamboost gains on top of just<br />> >> fq_codel. Since it appears that they are doing so fairly heavy-handed<br />> >> traffic shaping.<br />> >><br />> >> -Aaron<br />> >><br />> >><br />> >> On Fri, Jan 24, 2014 at 12:48 PM, Dave Taht <dave.taht@gmail.com><br />> wrote:<br />> >>><br />> >>> An interesting new chipset:<br />> >>><br />> >>><br />> >>><br />> http://www.anandtech.com/show/7526/qualcomm-atheros-announces-new-internet-processor-lineup-ipq8064-and-ipq8062<br />> >>><br />> >>> And streamboost (of which fq_codel is a component) is getting good<br />> >>> reviews:<br />> >>><br />> >>><br />> >>><br />> http://www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-streamboost-really-work?start=1<br />> >>><br />> >>> --<br />> >>> Dave Täht<br />> >>><br />> >>> Fixing bufferbloat with cerowrt:<br />> >>> http://www.teklibre.com/cerowrt/subscribe.html<br />> >>> _______________________________________________<br />> >>> Cerowrt-devel mailing list<br />> >>> Cerowrt-devel@lists.bufferbloat.net<br />> >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />> >><br />> >><br />> >><br />> >> _______________________________________________<br />> >> Cerowrt-devel mailing list<br />> >> Cerowrt-devel@lists.bufferbloat.net<br />> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />> >><br />> <br />> <br />> <br />> --<br />> Dave Täht<br />> <br />> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />></p>
</div></font>