[Cerowrt-devel] tp-link 4300 evaluation

[Lance Hepler]

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

> On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130527/248face0/attachment-0002.html>