From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7453921F0BA for ; Wed, 28 Aug 2013 11:44:49 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k18so1285682qcv.27 for ; Wed, 28 Aug 2013 11:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RcQ8sujTNdSCobs3U3gLxIXm3Akp56SXXxximss/COc=; b=RrNvuS4IfmHONMyYYT3s08qJXBU5M8PToi8cjjDtvftxnlFsOdwDJd5IId32UPCkYv PC5MfnD7FjinXNIaHGawXrmPtfCDVQFSnt7h5J9gREm9XvD04gLs2S5saaNlZ5QI/Zgl F63YljwoFnBhr+sr210bbJPSg4iJUprcyfMle7adM9WOcU+knBwnArzjv2nwm1XEIJYe Q25eqAX5htgKo7sHB7fRjbkv6Ck/TM31nPu10XLRUqm0dmEzI+obMDrNW6/NKONlPiZH KCDwL0qJYh1TIZ0rQqjfWCJDdoT56o1N9iyI/0aqptvqINUhYty2BO3DTlayb9BDwtOi se2A== MIME-Version: 1.0 X-Received: by 10.49.52.41 with SMTP id q9mr19424440qeo.32.1377715488000; Wed, 28 Aug 2013 11:44:48 -0700 (PDT) Received: by 10.224.60.137 with HTTP; Wed, 28 Aug 2013 11:44:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Aug 2013 11:44:47 -0700 Message-ID: From: Dave Taht To: Collin Anderson Content-Type: multipart/alternative; boundary=047d7bea3f3c4392d704e50662e7 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] hardware suggestions? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 18:44:49 -0000 --047d7bea3f3c4392d704e50662e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrot= e: > 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 > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --047d7bea3f3c4392d704e50662e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The stuff based on the atheros ath9k and ar= 71xx chipset (the wndr3800 and about 50 other products) are the most thorou= ghly 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 the= re 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 edg= erouter 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 co= st about $430 each.

As for "send statistics and crash reports". Well, tackl= ing the latter first - there generally is very little data left over after = an OS crash. As for statistics... there are a zillion useful statistics tha= t I would not mind collecting -=A0 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 g= etting 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 gi= ving up and going to a separate statistics collection box that wasn't t= he home gateway. In some ways I'm going the same way, leveraging the &q= uot;beaglebone black" presently for rrul, snmp, mrtg, smokeping, and o= wamp measurements - but certainly would like to continue having at least so= me stuff on the gw itself.

So I'd certainly love it if someone were to propose tackling g= ood statistics creation, collection, and measurement and get some code done= .=A0 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 a= ctually kind of possible, in that they all have netperf and netserver in th= em, but I do not open up the ports by default, and there would need to be s= ome 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<= br> and crash reports" box. I'm not much of a kernel hacker myself. I<= br> 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=E4ht

Fixi= ng bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.ht= ml=20
--047d7bea3f3c4392d704e50662e7--