[Cerowrt-devel] tp-link 4300 evaluation

Mon May 27 09:13:38 EDT 2013

On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler at gmail.com> wrote:

> 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.
>

> 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.

> 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.

> (Maybe a Xilinx Zynq-based router funded through Kickstarter? =)
>

I am very, very, very, very impressed with the potential of the zynq.

I have dreamed of having writable hardware that could access *virtual
memory* - which the zynq  can do!!! (at least theoretically)

Aformentioned dream I've sadly held now for over two decades.

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.

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.

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)

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...

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.

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...

Anyway, I digress (amd is also unifying vm space with their cpu/graphics
designs btw)...

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.

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?

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.)

(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. )

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.

http://www.parallella.org/'s initial board bringup is going very well...

> 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...

and perhaps the AR8327N switch chip could use someone poking about its
> driver
>

It's a switch, how bad can it be?

> (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.
>

I don't know why performance is as bad as it is in my initial benchmark.

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.

> 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...

>
> Lance
>
> 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..
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130527/25bd1db9/attachment-0002.html>