Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: dpreed@reed.com
To: "Dave Taht" <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] a new chipset and elsewhere a review of streamboost
Date: Fri, 24 Jan 2014 13:29:12 -0500 (EST)	[thread overview]
Message-ID: <1390588152.64884025@apps.rackspace.com> (raw)
In-Reply-To: <CAA93jw7cE8WdkG2S_=-Q79sNG-HrkfTE5R+zkM_Kys2Mng5oxg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5329 bytes --]


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


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



> On Fri, Jan 24, 2014 at 7:28 AM, Maciej Soltysiak <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
> 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@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@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@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äht
> 
> 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
>

[-- Attachment #2: Type: text/html, Size: 7037 bytes --]

  reply	other threads:[~2014-01-24 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-24 11:48 Dave Taht
2014-01-24 12:06 ` Aaron Wood
2014-01-24 12:28   ` Maciej Soltysiak
2014-01-24 13:15     ` Dave Taht
2014-01-24 18:29       ` dpreed [this message]
2014-01-24 23:54         ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1390588152.64884025@apps.rackspace.com \
    --to=dpreed@reed.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox