On Mon, May 27, 2013 at 6:13 AM, Dave Taht <dave.taht@gmail.com> wrote:

On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler@gmail.com> 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