From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (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 D4E5021F1DA for ; Mon, 27 May 2013 14:08:59 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id z16so4134773ead.38 for ; Mon, 27 May 2013 14:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hS7ZM0i1p49hdQpYUfyZDmyOefUS5mfxCQHEwnkidv4=; b=MfPM7v/QStamHF+RSmKag2EIRGdABed/jJrX6nCFKzd4PLLRrFhLb2ibF9prHtF/Fu UDi0Zp9h5SQnqrFTAQ4mCeRUeRMTdr/IegmVitR4wkA1uDvKNzHulkDdQ09lR5eLOOqa 1ejKJO7eCf8ZjQULQWTlL1XLMSn9WIDN78RkkbpqMt3ZSbM55SHcsEQiMCzdgsiz/Ynq IAV8dVLcm3iAJs30LPSYQ9wLnZTScfLithv/9SwigD5hET+jVPzjz6PC6KFPWSvVConn YlgwHQGPxH0lKu8pReuz6uEnPEjYyVkwoWy1PGQv1rllbnpwNVhOZPlgfvbgjFQE8l18 6hTQ== X-Received: by 10.15.76.133 with SMTP id n5mr11452585eey.105.1369688937483; Mon, 27 May 2013 14:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.13.217 with HTTP; Mon, 27 May 2013 14:08:17 -0700 (PDT) In-Reply-To: References: From: Lance Hepler Date: Mon, 27 May 2013 14:08:17 -0700 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a11c38e2c92717d04ddb98e67 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] tp-link 4300 evaluation 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: Mon, 27 May 2013 21:09:00 -0000 --001a11c38e2c92717d04ddb98e67 Content-Type: text/plain; charset=UTF-8 On Mon, May 27, 2013 at 6:13 AM, Dave Taht wrote: > On Sun, May 26, 2013 at 6:23 PM, Lance Hepler wrote: > >> I'd be interested in your netperf testing setup. >> > > The test we've been developing is called the rrul test. The prototype > (which is working quite well is at: > > https://github.com/tohojo/netperf-wrapper > > I use the results in my talks a lot. > Ahh! Neato! I'll have to play with this! With the AR71xx chips going out of style, the AR934x series is probably our >> best bet for readily consumer-available hardware with open-source friendly >> SoCs. >> > > It seems like it. But with MIPS Technologies effectively defunct the only > real hope I have for architectural progress on that architecture would come > from a licensee with chops. > You raise a good point. > So there is certainly room to drop most of the extra stuff in the > zedboard, design a new board around the zynq for a new-age cero router > around it (8 ethernet phys, 2-3 of which being SFP+ and gpon capable), add > pcie for 2 radios, pins to do software radio as development continues, > arduino headers, and dunno, battery support? > Sounds like the beginning of a kickstarter project. =) > When I get back to california next week, I hope to find someone to talk to > at Xilinx (suggestions, anyone?) about getting started on getting a board > like that designed. > I'm sure someone in UCSD's vast CS department does. I'll ask around. This is all pretty new stuff, perhaps some more performance can be gleaned >> by tuning the compiler optimizations (-march=74Kc?), >> > > Usually compiler options are not worth all that much. I didn't much care > for the deep pipeline in this design either... > Yea, true. And the design may be deep, but it's dual-issue with ooo-dispatch. It's definitely a lot beefier, though perhaps some basic benchmarking (CoreMark?, Dhrystone?) might be in order to set reasonable expectations for relative performance. We spent a lot of time oprofiling things in the early days of the ar7xx, I > will take a harder look as I get time this week. I'm not writing it off, > just was very disappointed in what I got initially. The other deal killer > for this platform is that 16MB of flash is a requirement for cerowrt's > boatload of test tools. > The thought of oprofiling these modules hurts. As for the flash, that's why I was looking at the NETGEAR models. Plenty of storage if we can get past the NAND issues. Helpfully, the WNDR4300 has 128MB of NAND flash, as does the WNDR3700v4. So >> compiling a full CeroWRT distribution shouldn't be a problem. The fixeth >> script will need to be changed, but not much else. >> > > ah, you've looked deeply at the boot phase. Applause! Bringing up this > board seems easy once the flash issues are resolved... but that requires a > level of time (with a scope probably) that I am personally unwilling to > invest right now. I think there are people on the problem, tho... > Yes I have, thank you! I've dedicated this weekend to trying to grok how openwrt is architected, how cerowrt differs, and where all its magic bits are hidden. Thankfully everything is well-architected, so discovery has been relatively straightforward. The hardest part was trying to figure out all those layers of nested and dynamic board configuration in target/linux/*/image/Makefile. Lance --001a11c38e2c92717d04ddb98e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 27, 2013 at 6:13 AM, Dave Taht <dave.taht@g= mail.com> wrote:
On Sun, M= ay 26, 2013 at 6:23 PM, Lance Hepler <nlhepler@gmail.com> wrote= :
I'd be intere= sted in your netperf testing setup.
The test we've been developing is called the rrul test. The prototype (= which is working quite well is at:

https://github.com/tohojo/netperf-wrapper

I use the results in my talks a lot.
<= br>
Ahh! Neato! I'll have to play with this!

With the AR71xx chips going out of style, the AR934x series is pr= obably our best bet for readily consumer-available hardware with open-sourc= e friendly SoCs.

It seems like it. But with MIPS Technolog= ies effectively defunct the only real hope I have for architectural progres= s on that architecture would come from a licensee with chops.

You raise a good point.=C2=A0
<= div>=C2=A0
<= div>So there is certainly room to drop most of the extra stuff in the zedbo= ard, design a new board around the zynq for a new-age cero router around it= (8 ethernet phys, 2-3 of which being SFP+ and gpon capable), add pcie for = 2 radios, pins to do software radio as development continues, arduino heade= rs, and dunno, battery support?

Sounds like the beginning of a= kickstarter project. =3D)
=C2=A0=C2=A0
When I get b= ack to california next week, I hope to find someone to talk to at Xilinx (s= uggestions, anyone?) about getting started on getting a board like that des= igned.

I'm sure someone in UCSD&#= 39;s vast CS department does. I'll ask around.

This is all pretty new stuff, perhaps some more performance can b= e gleaned by tuning the compiler optimizations (-march=3D74Kc?),

Usually compiler options are not worth al= l that much. I didn't much care for the deep pipeline in this design ei= ther...

Yea, true. And the desi= gn may be deep, but it's dual-issue with ooo-dispatch. It's definit= ely a lot beefier, though perhaps some basic benchmarking (CoreMark?, Dhrys= tone?) might be in order to set reasonable expectations for relative perfor= mance.

We spent a lot of time oprofiling things in the early days of the ar7xx,= I will take a harder look as I get time this week. I'm not writing it = off, just was very disappointed in what I got initially. The other deal kil= ler for this platform is that 16MB of flash is a requirement for cerowrt= 9;s boatload of test tools.

The thought of oprofiling thes= e modules hurts. As for the flash, that's why I was looking at the NETG= EAR models. Plenty of storage if we can get past the NAND issues.

Helpfully, the WNDR4300 has 128MB of NAND flash, as d= oes the WNDR3700v4. So compiling a full CeroWRT distribution shouldn't = be a problem. The fixeth script will need to be changed, but not much else.=

ah, you've looked deeply at the boot = phase. Applause! Bringing up this board seems easy once the flash issues ar= e resolved... but that requires a level of time (with a scope probably) tha= t I am personally unwilling to invest right now. I think there are people o= n the problem, tho...

Yes I have, thank you! I'v= e dedicated this weekend to trying to grok how openwrt is architected, how = cerowrt differs, and where all its magic bits are hidden. Thankfully everyt= hing is well-architected, so discovery has been relatively straightforward.= The hardest part was trying to figure out all those layers of nested and d= ynamic board configuration in target/linux/*/image/Makefile.

Lance
--001a11c38e2c92717d04ddb98e67--