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