[Cerowrt-devel] tp-link 4300 evaluation

[Cerowrt-devel] tp-link 4300 evaluation

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

I am still on a quest to find a suitable netgear 3800 replacement. Paul
Vixie found the same chipset (I hope!)
being marketed as the WNDR3800-100NAS
http://www.newegg.com/Product/Product.aspx?Item=N82E16833122434
so I have less fear about having to make the switch.

That said there are a few products on the market from buffalo and tplink
that are readily available on shelves today that seemed to be worth trying.

esr and I picked up a tp-link 4300 (89 retail) for evaluation yesterday. At
first glance it looked like a substantial update to the wndr3800 as it has
a two generation leap forward on the chipset, using the Atheros AR9344 rev
2, which features the MIPs 74k processor, which supposedly is twice as fast
as the 24k in the wndr3800. The box runs at a lower clock rate (540Mhz)
than the netgear 3800 (680), but I figured the better processor would win,
even if it got most of its theoretical win from an overly deep cpu pipeline.

I built openwrt for it, as I haven't built pure openwrt in a while... and
this device only has 8MB of flash, and I didn't
feel like stripping down cerowrt at the time.

+ There is a new skin for the luci gui which is quite nice, I don't know
why I haven't been using it.
+ It was neat to see the ipv6 relay thing work
+ Procd worked for the first time (I've been trying to switch to this in
cero for a while)
- Then I started poking into the forwarding performance...

Cerowrt regularly achieves 300+Mbit of ethernet forwarding performance in
netperf. the tplink barely gets 130. the marketing for the tplink calls it
a "n750" adding up the max theoretical values for the wifi channels, but I
doubt, given what I get on ethernet, that it even comes close to that in
reality.

It turns out on the tplink there is only one ethernet chip, which is
vlan-ed from the internal switch to the external port, instead of the two
that are in the wndr3800.

Now, there are quite a few differences between the software loads of
openwrt and of cerowrt - notably the openwrt build is bridged to the wifi
(I turned off the bridge, no difference in performance), and the default
atheros build currently has some de-optimizations in it to handle unaligned
access to packets that I don't think are needed on this later chipset,
but... it currently looks like in the quest for cost reduction, this step
forward to "modern" hardware is actually a large step backwards.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 2789 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Lance Hepler]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

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. 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. (Maybe a Xilinx
Zynq-based router funded through Kickstarter? =)

This is all pretty new stuff, perhaps some more performance can be gleaned
by tuning the compiler optimizations (-march=74Kc?), and perhaps the
AR8327N switch chip could use someone poking about its driver (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.

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.

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

[-- Attachment #2: Type: text/html, Size: 1510 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 1896 bytes --]

On Sun, 26 May 2013, Lance Hepler 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.

As I understnad it, the difference between the WNDR3700v4 and WNDR4300 is that 
the 4300 has a slightly better wireless chip.

Unfortunantly from what I've seen so far, they did something wierd with the 
storage and as a result the stock openwrt can't access it. I've seen reports of 
people getting it to run from an initramfs, but this means that no settings can 
be preserved across reboot.

If you've seen anything different, I'd be very interested to hear about it (I 
picked up a 3700v4 and a couple 4300's for testing)

David Lang

> I'd be interested in your netperf testing setup. 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. (Maybe a Xilinx
> Zynq-based router funded through Kickstarter? =)
>
> This is all pretty new stuff, perhaps some more performance can be gleaned
> by tuning the compiler optimizations (-march=74Kc?), and perhaps the
> AR8327N switch chip could use someone poking about its driver (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.
>
> 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.
>
> 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..
>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 164 bytes --]

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

On Mon, May 27, 2013 at 2:32 AM, David Lang <david@lang.hm> wrote:

> On Sun, 26 May 2013, Lance Hepler 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.
>>
>
> As I understnad it, the difference between the WNDR3700v4 and WNDR4300 is
> that the 4300 has a slightly better wireless chip.
>
> Unfortunantly from what I've seen so far, they did something wierd with
> the storage and as a result the stock openwrt can't access it. I've seen
> reports of people getting it to run from an initramfs, but this means that
> no settings can be preserved across reboot.
>
> If you've seen anything different, I'd be very interested to hear about it
> (I picked up a 3700v4 and a couple 4300's for testing)
>

according to a birdie, "it looks like it's an ONFI with quirks, or nobody
has realised that it's ONFI at all.". Perhaps that's enough clue to get
someone started? but I fear jtag debugging will be needed. Flash chips tend
to have interesting race conditions....


> David Lang
>
>
>  I'd be interested in your netperf testing setup. 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. (Maybe a
>> Xilinx
>> Zynq-based router funded through Kickstarter? =)
>>
>> This is all pretty new stuff, perhaps some more performance can be gleaned
>> by tuning the compiler optimizations (-march=74Kc?), and perhaps the
>> AR8327N switch chip could use someone poking about its driver (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.
>>
>> 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.
>>
>> 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 4091 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[David Lang]

On Mon, 27 May 2013, Dave Taht 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.
>>>
>>
>> As I understnad it, the difference between the WNDR3700v4 and WNDR4300 is
>> that the 4300 has a slightly better wireless chip.
>>
>> Unfortunantly from what I've seen so far, they did something wierd with
>> the storage and as a result the stock openwrt can't access it. I've seen
>> reports of people getting it to run from an initramfs, but this means that
>> no settings can be preserved across reboot.
>>
>> If you've seen anything different, I'd be very interested to hear about it
>> (I picked up a 3700v4 and a couple 4300's for testing)
>>
>
> according to a birdie, "it looks like it's an ONFI with quirks, or nobody
> has realised that it's ONFI at all.". Perhaps that's enough clue to get
> someone started? but I fear jtag debugging will be needed. Flash chips tend
> to have interesting race conditions....

Given that we have the GPL source for the kernel available from Netgear, I'm a 
little puzzled that we are having to reverse engineer this instead of working 
from the source.

Even if the first version was little more than a cut-n-paste of the netgear 
butchered driver until people have time to analyse it fully.

David Lang

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Lance Hepler]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Mon, May 27, 2013 at 6:33 AM, David Lang <david@lang.hm> wrote:

> On Mon, 27 May 2013, Dave Taht 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.
>>>>
>>>>
>>> As I understnad it, the difference between the WNDR3700v4 and WNDR4300 is
>>> that the 4300 has a slightly better wireless chip.
>>>
>>> Unfortunantly from what I've seen so far, they did something wierd with
>>> the storage and as a result the stock openwrt can't access it. I've seen
>>> reports of people getting it to run from an initramfs, but this means
>>> that
>>> no settings can be preserved across reboot.
>>>
>>> If you've seen anything different, I'd be very interested to hear about
>>> it
>>> (I picked up a 3700v4 and a couple 4300's for testing)
>>>
>>>
>> according to a birdie, "it looks like it's an ONFI with quirks, or nobody
>> has realised that it's ONFI at all.". Perhaps that's enough clue to get
>> someone started? but I fear jtag debugging will be needed. Flash chips
>> tend
>> to have interesting race conditions....
>>
>
> Given that we have the GPL source for the kernel available from Netgear,
> I'm a little puzzled that we are having to reverse engineer this instead of
> working from the source.
>
> Even if the first version was little more than a cut-n-paste of the
> netgear butchered driver until people have time to analyse it fully.


Found the original NAND driver. If you download the original fw source it's
in wndr4300-GPL.git/git_home/linux.git/drivers/mtd/nand/ath_nand.c. It also
borrows a few things from
wndr4300-GPL.git/git_home/linux.git/arch/mips/include/asm/mach-atheros/atheros.h.

I'm already seeing lots of similarities to the ar934x_nfc.c flash
controller driver in upstream openwrt. That one seems to be missing some of
the ECC features of the original ... and all of the ONFI bits...

I'll poke at it some this week, see if I can bring something up.

Lance

[-- Attachment #2: Type: text/html, Size: 3242 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 6405 bytes --]

On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 8552 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Lance Hepler]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]

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

> On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler@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

[-- Attachment #2: Type: text/html, Size: 5928 bytes --]

Re: [Cerowrt-devel] tp-link 4300 evaluation

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 8020 bytes --]

On Mon, May 27, 2013 at 2:08 PM, Lance Hepler <nlhepler@gmail.com> wrote:

> On Mon, May 27, 2013 at 6:13 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Sun, May 26, 2013 at 6:23 PM, Lance Hepler <nlhepler@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!
>

Prior to that, everybody was testing up, down, and ping separately, and not
testing TCP. I'm hoping somebody like speedtest gets around to testing all
that at the same time one day soon.

In the meantime it's darn useful in a wide variety of scenarios.

I add the "best of" tests to:

http://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery

I'm a little behind, I have some good ones on wifi that I've used in
various presos, as well as of rtt fairness and of ipv6 vs ipv4. The tests
continue to evolve, more recently adding equivalents to the cisco pie
tests, etc.

Still needed are a good VOIP and a good DASH test, and I'd like very much
to start collecting statistics on how much classification is mangled on the
wild and wooly internet. Toke is buried with his thesis...

We have several public netperf servers available (hope to add more), but
it's easy to just put up one of your own somewhere. Just compile netperf
from svn with the --enable-demo option on your clients and servers.

cero comes with netserver enabled by default on your internal interfaces.
It does NOT scale to the highest bandwidths available but is useful for
testing low rate shapers.



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

Sigh. I liked MIPS. But arm has leapfrogged 3 generations to MIPS's one...

Arm chips almost universally have their wifi interfaces hooked up via a
very slow bus (usb or spi), and are rife with binary blobs in most of their
incarnations (android,  marvel, are big offenders) Few have a decent
ethernet chip, or more than 1.

PPC might re-enter this market.

So you could look at all this as a problem or an opportunity to arduinize
the edge of the net.

At the moment it seems best long term to leverage all the activity on arm,
particularly on the server attempts and the FPGA combos to make progress
forward.

Given that the first generation 802.11ac devices don't support multi-user
MIMO apparently, there is room to innovate here in the next, next
generation of edge hardware vs the established majors.


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

I was a big fan of the netfpga.org project but their current 10GigE
direction is very expensive and not as useful as trying to do a standalone
board < 500 dollars cost.

Sadly I think that the kickstarter funding model requires a project
considerably further along than "we need to design a cool board to fix the
internet with the software we've already developed". Kickstarter is more of
a "we are on our last gasp and we just need a little help to ship something
useful" model. So angels or VCs or deep pockets would be required to get a
zedboard.org-for-a-better-router project off the ground. And my verilog is
very rusty.

The zynq idea is a bit longer term than the immediate emergency of trying
to find a 3800 replacement, and funding in general is rather scarce. Would
have loved to have started the zynq project 6 months ago tho. We'd have
something REALLY COOL now.


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

That would be helpful. They are just down the street from me but their
website makes it really hard to find someone to shoot the breeze with.


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

I don't believe in benchmarks like that for embedded. irq response time,
dma are more important. I'll rip out the unaligned access hacks in the next
build tho... those are usually hell on pipelined arches.


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

Oh, no, it's fun. You are always surprised by the results, and sometimes
easy fixes result in huge gains. It's a good way to stay in touch with the
real reality instead of optimising for stuff that isn't important.


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

Looks like progress might be made this week! I'm rooting for everyone. Kind
of deep into android at the moment myself...

>
> 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 think you are the first person to ever have read /etc/init.d/boot. I note
that I think that's the problem in getting the new procd daemon to work
right....

I still remain unsure that the oddball device naming scheme in cero is a
good idea. Certainly it makes better firewall rules possible... and fw3
supports the + syntax - but it's not something people have adopted to any
extent, sooo...



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

I note that cerofiles is a bit out of date. I don't think it's terribly out
of date, I just haven't pushed it with the last couple builds being
buggy....


>
> Lance
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 13211 bytes --]