[Bloat] [Cerowrt-devel] failing to find the "declared victory" in a current wifi router

[Dave Taht]

GWB declared victory too early also, so...

0) ubnt's edgerouter series from the X (49 dollars) to the pro - (8
ports, 300 dollars) also has made an investment in making fq_codel and
smart queuing easy to use over their last 3 generations of firmware.
Vers

They are debian based (and closely related to Vyos (formerly vyatta),
which also has gained fq_codel support)

1) At the time development ceased directly on cerowrt, all the major
home router vendors were planning to release for the christmas season,
devices with vastly upgraded shaping and queue management, QoS
features - so life was looking promising. And we worked on refining
edge cases and moving code upstream into other places in addition to
openwrt.

All those vendors goofed in some way or another, but did feature
"Traffic shaping with X" prominently on the box, where X was
Streamboost, Dynamic QoS or some other new marketing catchphrase, with
a lovely gui - netgear's X4 gui was particularly promising... and
their implementation the best of what I benchmarked - but the X4 was
very flaky wifi-wise... and every vendor had no way to turn off nat.
Buffalo may have got it more right but I never got around to test it
(they use dd-wrt).

all of them missed the need for framing compensation on dsl and ppoe
technologies. I realize that getting these right is a human factors
nightmare, but you have to get them right.

Also from a human factors perspective, people seemed to think people
wanted pinpoint control of bandwidth for everything, and developed
guis and tools and invasive means (like streamboost doing dpi) to do
so.

d-link shipped a version of streamboost lacking codel entirely.
Another version of their product did good downstream prio but lousy
upstream, and fq_codel + sqm-scripts smoked it:

http://forums.dlink.com/index.php?topic=61634.0;nowap

I tore apart (as publicly as possible!) the flaws in each vendor's
implementation earlier this year, and asus, at least, has responded
with newer firmware. Most vendors are plagued with 5+ year old
kernels, still, and it is only the ones that were on 3.4 or later that
could respond.

And, we, here, missed the fact that all these new high end home
routers used TSO/GSO and especially GRO, heavily, and we had not
compensated for that.

Cake is a great candidate for the edgerouters and the new higher end gear.

Aside from that, on the low end mikrotik has made some encouraging noises.

So I do have hope that THIS christmas, effective and correct qos and
shaping implementations will begin to arrive across the board.

Also the first pie enabled cablemodems should start appearing late
this summer for test, and I have a bit of hope for seeing an
integrated cablemodem/wifi device from some vendor of showing up also.


On Mon, Jul 6, 2015 at 6:02 PM, Joe Touch <touch at isi.edu> wrote:
> Hi, all,
>
> I'm posting because of my recent frustration with the claim that
> bufferbloat solutions have been "pushed up into the OpenWRT and
> commercial routers.
>
> I spent the bulk of last weekend trying to find a COTS WIFI router that
> supported OpenWRT with bufferbloat (SQM) extensions.
>
> I tried a Linksys WRT1200AC, and here's what I found:
>
>         - Kaloz's 23-Apr-2015 build installs fine and comes up
>         with a web server (LUCI), but does NOT include SQM
>
>                 - trying to install the SQM packages fails
>                 due to a kernel version incompatibility
>                 (for a 23-Apr-2015 build?!)
>
>         - CC-rc2 doesn't have a WRT1200AC build
>         presumably I should have used mvebu-armada-385-linksys-caiman,
>         but it's not at all clear
>
>                 - and I'd have to install LUCI and/or reinstall
>                 factory firmware from the command line, and none
>                 of that is all that clear, esp. a recovery route
>                 that doesn't involve voiding warranty to wire in
>                 a serial port
>
> Given the "declared victory" (http://www.bufferbloat.net/news/53),
> perhaps someone one one of these lists can explain why there's no clear
> information on a current device that supports a current build that
> actually supports these fixes?
>
> I.e., if you were trying to make this obscure, you're doing a very good job.
>
> FWIW.
>
> Joe
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast