<div dir="ltr">On Mon, May 27, 2013 at 6:13 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="color:rgb(80,0,80)">On Sun, May 26, 2013 at 6:23 PM, Lance Hepler </span><span dir="ltr" style="color:rgb(80,0,80)"><<a href="mailto:nlhepler@gmail.com" target="_blank">nlhepler@gmail.com</a>></span><span style="color:rgb(80,0,80)"> wrote:</span><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'd be interested in your netperf testing setup. </div></div></blockquote></div><div><br>
The test we've been developing is called the rrul test. The prototype (which is working quite well is at:<br>
<br><a href="https://github.com/tohojo/netperf-wrapper" target="_blank">https://github.com/tohojo/netperf-wrapper</a><br>
<br>I use the results in my talks a lot.<br></div></div></blockquote><div><br></div><div>Ahh! Neato! I'll have to play with this!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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. </div>
</div></blockquote></div><div><br>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. <br></div>
</div></blockquote><div><br></div><div>You raise a good point. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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?<br>
</div></div></blockquote><div><br></div><div>Sounds like the beginning of a kickstarter project. =)</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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.<br>
</div></div></blockquote><div><br></div><div>I'm sure someone in UCSD's vast CS department does. I'll ask around.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This is all pretty new stuff, perhaps some more performance can be gleaned by tuning the compiler optimizations (-march=74Kc?), </div>
</div></blockquote></div><div><br>Usually compiler options are not worth all that much. I didn't much care for the deep pipeline in this design either...</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>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.</div>
</div></blockquote></div><div><br>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...<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Lance</div></div></div></div>