[Cerowrt-devel] a new chipset and elsewhere a review of streamboost

Fri Jan 24 18:54:26 EST 2014

On Fri, Jan 24, 2014 at 1:29 PM,  <dpreed at reed.com> wrote:
> 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.

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 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.

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 90s 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-adapteva/

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 lot,
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, outside
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 mobile)
> 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" <dave.taht at gmail.com> said:
>
>> On Fri, Jan 24, 2014 at 7:28 AM, Maciej Soltysiak <maciej at 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
>> 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=101052&posted=1#post101052
>>
>> one takeaway from that review was...
>>
>> the next job facing us is to make-wifi-fast again, in increasingly crowded
>> radio
>> conditions, in a world where people insist on running HD video over it at
>> 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 <woody77 at gmail.com> 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 <dave.taht at gmail.com>
>> wrote:
>> >>>
>> >>> An interesting new chipset:
>> >>>
>> >>>
>> >>>
>>
>> http://www.anandtech.com/show/7526/qualcomm-atheros-announces-new-internet-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-qualcomms-streamboost-really-work?start=1
>> >>>
>> >>> --
>> >>> Dave Täht
>> >>>
>> >>> Fixing bufferbloat with cerowrt:
>> >>> http://www.teklibre.com/cerowrt/subscribe.html
>> >>> _______________________________________________
>> >>> Cerowrt-devel mailing list
>> >>> Cerowrt-devel at lists.bufferbloat.net
>> >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Cerowrt-devel mailing list
>> >> Cerowrt-devel at lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> >>
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html