Re: [Cerowrt-devel] hardware suggestions?

[Dave Taht <dave.taht@gmail.com>]

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

The stuff based on the atheros ath9k and ar71xx chipset (the wndr3800 and
about 50 other products) are the most thoroughly debufferbloated and well
understood products at the moment.

If you wish to track cerowrt directly, the wndr3800 is the only way to go.

Otherwise all of openwrt and dd-wrt support fq_codel now in their QoS
systems, so you can adopt one of the 150+ platforms supported there and see
what happens.... YMMV.

I have been on a quest for newer/faster home gw hardware to work on for
over a year, without much success. Recently a few plug-like products have
appeared that have a lot of raw potential as more powerful home gateways,
but their kernels are ancient... I recently did build an openwrt kernel for
a dreamplug and a edgerouter lite that might be useful... and I have been
using some atom based boxes with debian with great success in the gigE
range as well, but they cost about $430 each.

As for "send statistics and crash reports". Well, tackling the latter first
- there generally is very little data left over after an OS crash. As for
statistics... there are a zillion useful statistics that I would not mind
collecting -  smokeping vs mrtg being a favorite - but establishing an
infrastructure for doing so in a sane and secure manner is kind of hard.
(I've long hoped to leverage an existing one, but just getting the OS code
out the door on a semi-regular basis eats nearly all my time, and the rest
I spend on researching more bufferbloat fixes and trying to move the
industry forward.)

The bismark project made some strides in this direction before giving up
and going to a separate statistics collection box that wasn't the home
gateway. In some ways I'm going the same way, leveraging the "beaglebone
black" presently for rrul, snmp, mrtg, smokeping, and owamp measurements -
but certainly would like to continue having at least some stuff on the gw
itself.

So I'd certainly love it if someone were to propose tackling good
statistics creation, collection, and measurement and get some code done.
One idea that I like is the idea of edge to edge measurements with p2p
testing (rather than peer to server) between cerowrt routers. That's
actually kind of possible, in that they all have netperf and netserver in
them, but I do not open up the ports by default, and there would need to be
some sort of rendevous mechanism.





On Mon, Aug 26, 2013 at 5:44 PM, Collin Anderson <cmawebsite@gmail.com>wrote:

> Hi All,
>
> After 5 years of knowingly suffering from high latency from uploads
> through Comcast, I have finally discovered the term "bufferbloat" and
> am glad to see that at least some people are pushing for better
> queuing algorithms. I use ssh all day for making websites at work and
> would like to eliminate, or at least reduce latency from buffer bloat.
>
> What hardware should I buy? Netgear WNDR3800? I want to buy the same
> hardware as you all so when I find repeatable bugs I can complain and
> you can reproduce them. :) I want something reliable and easy to get
> set up and configure.
>
> Also, if you want to get some data and find bugs with CeroWRT, it
> would be cool if I could just install it and check a "send statistics
> and crash reports" box. I'm not much of a kernel hacker myself. I
> mostly stick with making websites with python. If I'm not helping to
> improve CeroWRT, I might as well use OpenWRT if it has decent AQM and
> is a little more reliable.
>
> Thanks,
> Collin
> _______________________________________________
> 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

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