<br><br><div class="gmail_quote">On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <span dir="ltr"><<a href="mailto:nlhepler@gmail.com" target="_blank">nlhepler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>That's tragic. I just picked up a Netgear WNDR4300 (openbox on sale at the local Fry's) to see if I could hack up a CeroWrt clone on it. It seems to be mostly the same hardware as the WNDR3700v4 and the TP-Link WDR43[01]0, with things just wired up slightly differently. <br>
</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>


<br></div><div>I'd be interested in your netperf testing setup. </div></div></blockquote><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">https://github.com/tohojo/netperf-wrapper</a><br>
<br>I use the results in my talks a lot.<br> <br></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><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>(Maybe a Xilinx Zynq-based router funded through Kickstarter? =)</div>
</div></blockquote><div><br>I am very, very, very, very impressed with the potential of the zynq. <br><br>I have dreamed of having writable hardware that could access *virtual memory* - which the zynq  can do!!! (at least theoretically) <br>
<br>Aformentioned dream I've sadly held now for over two decades. <br><br>but when I poured through the zynq documentation I saw that it had one port that could go through the vm subsystem and jumped for joy.<br><br>Finally, something that could take hardware design out of the hands of the EEs (who tend to optimize for the wrong things) and back into userspace where real problems in real software can be offloaded easily, and solutions iterated in conjunction with the EEs and the huge mental and coding gap today between CS and EE closed again. <br>
<br>I was happy when virtual memory became standard on everything (late 80s) but very unhappy when everyone writing socs (early 90s) put all the cool accelerators for various things where you could only easily get at them via a switch to kernel mode. The EEs missed the benefits of userspace and vm entirely until the zynq showed up (and it has twisted software design into moving things that shouldn't be in kernelspace into kernelspace)<br>
<br>I fondly remember the days when software and hardware skills were intermixed, that you could soldier together a real computer, write some software, and add something else to it to make it do something useful...<br><br>
Wait... all that's happening now again with the pi, beaglebone, etc - ! (the maker movement is pretty awesome) but those devices are a tad underpowered for the kinds of things I'd like to be doing. <br><br>An example of a highly parallizable task is implementing an echo canceller with a long tail. You kind of have to do this in userspace on something like a freeswitch, and switching to kernelspace to do it is a PITA for the very brief interval that doing echocan is useful...<br>
<br>Anyway, I digress (amd is also unifying vm space with their cpu/graphics designs btw)...<br>  <br>A big problem with the initial dev boards built around the zynq is they are built around two incompatible sets of ideas - one being that you want to do graphics and sound and the other being you want to do high speed wireless (and/or DSP processing), which drives the cost up. Not having both gigE ethernet ports brought out is currently a deal-killer for me.<br>
<br>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>
<br>The zynq-7020 is the coolest darn chip I've seen in ages. (I haven't been this excited about a chip since the strongarm. I kind of expect, after fiddling with my zedboards more to find something to be disappointed in.)<br>

<br>(I have a parallela board on order, there's an openwrt port for the 
zedboard in progress, and I've BQL'd the zynq kernel already, and looked
 over the verilog for various ethernet chips to see how to move fq_codel
 directly into hardware, etc, etc. )<br><br>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><br>
<a href="http://www.parallella.org/'s">http://www.parallella.org/'s</a> initial board bringup is going very well...<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">

<div><br></div><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><br>Usually compiler options are not worth all that much. I didn't much care for the deep pipeline in this design either...<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>and perhaps the AR8327N switch chip could use someone poking about its driver </div></div>
</blockquote><div><br>It's a switch, how bad can it be?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(the rtl8366s in the WNDR3800 _has_ been around a while). Although, in all honesty, the omission of that second ethernet port could just be a coffin nail.</div>

</div></blockquote><div><br>I don't know why performance is as bad as it is in my initial benchmark.<br><br>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>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">

<div><br></div><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><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>
<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<span><font color="#888888">

<div><br></div><div>Lance</div></font></span><div><br></div><div>PS: I apologize if this post doesn't show up where it should. I joined the list to respond to this email, as such I naturally didn't receive the original..</div>



</div>
<br>_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net" target="_blank">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>