New Asus RT-N16 Router

[ecaddict]

FTP usually uses streams (as I've told before) which doesn't need that much feedback. Also most of the data processing is done on kernel level and thus does not require much cpu and is faster. This allows the sending side a greater speed.

What you wrote above makes me wonder if you're familiar with sockets and how they are used. For the connected socket it does not matter if FTP or Samba writes 64K data. It just delivers it as a byte stream to the remote end. I have a pretty good guess that a whole 32/64K is given via a single write operation to the TCP stack. And from the moment on it takes ~8ms to finish that operation (in case of 64K). Samba has nothing to do during this time.

So yes, I think it's obvious why it's slower, even when I don't really like it

So you say that it's obvious to you why "uploading" (using TCP) via Samba is faster than downloading (also using TCP) even though due to journalling "uploading" requires extra processing and CPU cycles?

If it's so obvious forgive me not commenting any-more what you write as it seems you're not interested in solving this puzzle.

[wpte]

If it's so obvious forgive me not commenting any-more what you write as it seems you're not interested in solving this puzzle.

You don't have to be heat headed about all this...
I'm not trying to make a fool out of you or whatsoever.

Anyway, I've conducted a little test myself:
CPU time is the time given to a certain process to do calculating stuff.
Luckily Linux counts these times quite accurately and thus it's a good benchmark.

I'm downloading and uploading the very same file which is well over 3GB. (3.378.150.604 bytes if you must know)
I restart samba before up or downloading so the time is reset and the memory is erased.

So the times I got when watching the smbd process:
downloading from router to pc: 522 seconds
uploading from pc to router: 311 seconds

There is your clear difference in processing time...

Do you think that it's normal that "upload" is so much faster than download even though upload requires extra disk operation (extra CPU cycles)?

Linux thinks says something else.

Now not to make your theory somewhat incorrect we have these possible causes why Linux is saying no:

• The broadcom drivers are bad programmed - totally agree, still not sure if that causes this
• The bus the router uses to communicate doesn't like reading - quite unlikely
• The ethernet ports have wrong settings concerning packet size - bigger packet size is always good in a network with few clients and little mixed traffic, still it usually only increases performance with 5% or so
• Linux is wrong about the cpu time - well, could be in theory: maybe a kernel bug
• Samba is a non optimized program - also somewhat unlikely considering the popularity

now what do you think?

[ecaddict]

At least you're making some tests now.

Now not to make your theory somewhat incorrect we have these possible causes why Linux is saying no:

• The broadcom drivers are bad programmed - totally agree, still not sure if that causes this

Wrong. The ethernet driver deals with frames and it does no care if the IP packet carries UDP or TCP.
And the same ethernet driver can produce with NFS over UDP over 12 MB/s "download".

• The bus the router uses to communicate doesn't like reading - quite unlikely

I don't know what kind of bus you mean. If you mean the connection between the SoC (BCM4718) and ethernet chip (BCM53115) that probably also does not care if UDP or TCP is used or what direction frames are sent.

• The ethernet ports have wrong settings concerning packet size - bigger packet size is always good in a network with few clients and little mixed traffic, still it usually only increases performance with 5% or so

Wrong. Jumbo frames cannot be used as discussed earlier and otherwise as it can be seen from the capture maximum size ethernet frames (1500 bytes) are used (exception is the last one of the block, this is normal).

• Linux is wrong about the cpu time - well, could be in theory: maybe a kernel bug

I thought that you posted calendar time. Anyhow that's not the cause but the phenomenon.

• Samba is a non optimized program - also somewhat unlikely considering the popularity

Wrong. Not just Samba "upload" is faster than download. FTP or NFS over TCP has also this. Exception is NFS over UDP. It's faster in the "download" direction (and the fastest file transfer among any other protocols in any other direction).

So my suspect number one is still TCP.

I just don't have enough time to check this issue in depth in a decent book like TCP/IP Architecture, Design and Implementation in Linux (from Sameer Seth and M. Ajaykumar Venkatesulu).

[hggomes]

NEW ASUS FIRMWARE:

Description: ASUS RT-N16 Firmware Version 1.0.1.2

* Improve the stability of USB device
* Fixed bug that printer can't be found after power off
* Please use with V4.0.8.7 utilities together.

[hggomes]

SMALLNETBUILDER.COM ROUTERS BENCHMARKS
===================================

http://www.smallnetbuilder.com/index...mid=&chart=119

I just wonder how it's possible this ROUTERS PERFORMANCE BENCHMARKS are real or correct, let's take a look:

- ASUS RT-N16 (CPU: BCM4718 480MHZ RAM: 128MB DDR SWITCH: BROADCOM GIGABIT)

- LINKSYS E3000 (CPU: BCM4705 300MHZ RAM: 64MB DDR SWITCH: BROADCOM GIGABIT)

- LINKSYS WRT320N (CPU: BCM4717 420MHZ RAM: 32MB DDR SWITCH: BROADCOM GIGABIT)

*WAN TO LAN: RT-N16: 141.1MBps | E3000: 218.4MBps | WRT320N: 145.1MBps
*LAN TO WAN: RT-N16: 143.3MBps | E3000: 249.4MBps | WRT320N: 165.5MBps
*SIMULTANEOUS THROUGHPUT: RT-N16: 155.9MBps | E3000: 257.5MBps | WRT320N: 159.0MBps

The worst equipped router (E3000) it´s the better performer and vice versa, RT-N16 it's from far the better hardware based router (new broadcom generation cpu) and it's the worst performer. The same happen with other routers, LINKSYS routers, you can see WRT310N and 320N performing much better than WRT610N. Very weird this performances / benchmarks...

[lly]

The worst equipped router (E3000) it´s the better performer

I found different opinions about E3000 HW info, for example - http://en.wikipedia.org/wiki/Linksys_routers#E3000

Unfortunately, I can't found GPL firmware sources for E3000 at http://homesupport.cisco.com/en-us/gplcodecenter - might be interesting details inside.

I simply suspect that E3000 has much better stock firmware...

[ecaddict]

I simply suspect that E3000 has much better stock firmware...

Can it happen that they have a newer (better) ethernet driver? It would be so good to get rid of the crapy TCP performance...

E.g. TCP typically uses ~25% more ethernet frames (due to ACKs) than UDP (in large block transfer) and maybe newer driver has interrupt coalescing or some other trick (I don't know what is possible with this particular Broadcom chip).

Btw I've found some interesting AHB description (some other chip vendors use it+separate ethernet for WAN and LAN no VLAN tagging thus sharing bandwidth).

MIPS74kc may have ~30% advantage in CPU architecture compared to MIPS24Kc and higher clock but the SoC chip may not be that shiny as Broadcom states (or would like to see).

And Broadcom's attitude towards open source developers simply shocks me after all of this.

All of my respect goes to lly, theMIROn and other developers who have done such an excellent job despite the difficult situation.

Update: One more question, would TCP/UDP checksum calculation offload possible with these chips (or is it already used), so that MIPS CPU is not loaded with this?

[wpte]

Unfortunately, I can't found GPL firmware sources for E3000 at http://homesupport.cisco.com/en-us/gplcodecenter - might be interesting details inside.

you can request them to put it up it seems: http://linksys.custhelp.com/cgi-bin/...er/gpl_ask.php

not too bad, many companies don't have fancy GPL code request forms like that

[hggomes]

I found different opinions about E3000 HW info, for example - http://en.wikipedia.org/wiki/Linksys_routers#E3000

Unfortunately, I can't found GPL firmware sources for E3000 at http://homesupport.cisco.com/en-us/gplcodecenter - might be interesting details inside.

I simply suspect that E3000 has much better stock firmware...

Even that way, how it's possible the same hardware (and even worst, case of WRT320N) with so much diferences of performance? It's a HUGE diffence, something is not right...

PS: Wikipedia says WRT320N uses BCM4717 at 354MHZ instead of 420MHZ, so even "better", how the hell is faster than RT-N16, WRT600/610, etc...

Broadcom does not supply any kind of updated drivers?

Thank you all for replying

[lly]

Even that way, how it's possible the same hardware (and even worst, case of WRT320N) with so much diferences of performance? It's a HUGE diffence, something is not right...

From link you provided:

Routing performance for the E3000 using our standard test method is summarized in Table 1, along with the 610N's (V1) test results for comparison. Since the CPU is the same Broadcom BCM4705 for both routers , the E3000's higher performance can only be attributed to improved routing firmware. I don't have a 610N V2 to test. But I'd imagine that its current firmware would provide similar performance.

I didn't read their test methods carefully, but I suspect that E3000 has updated SDK & turned off some unnecessarily netfilter modules.

[ecaddict]

From link you provided:

I didn't read their test methods carefully, but I suspect that E3000 has updated SDK & turned off some unnecessarily netfilter modules.

Can this updated SDK mean some better C compiler? I know that MIPS 74Kc can re-order instructions but it checks only up to 8 instructions so quite much is left for the compiler.
How about the currently used compiler, can it handle this already or simply 24Kc code is generated which is compatible with 74Kc?

Update: This dual long 74Kc pipeline may require quite different code to run efficiently...

[wpte]

Can this updated SDK mean some better C compiler?

right now we use the same (modified & updated) toolchain as asus used in their WL-500 models.
Not sure if the RT-N16 toolchain is any different, but they are both based on gcc (which is quite a good compiler when you turn off the optimization off now and then) with uclibc.

What they used for compiling the pre-compiled drivers is still a mystery

SDK's also include drivers and api depending on the type of product it's for.

[hybriz]

I have no clue when it will be shipped.. but I can even buy spareparts now most distri's do not even want to do that

but WL-500w sucks for one reason, and that are the attached antenna's
I need the ability to connect an outdoor antenna to it

and the WL500gP(v1) is not for sale anymore..

www.ciudadwireless.com

WL500gP(v1) and V2 is sold at that website. it's a shop in Spain.

[necrolatry]

right now we use the same (modified & updated) toolchain as asus used in their WL-500 models.
Not sure if the RT-N16 toolchain is any different, but they are both based on gcc (which is quite a good compiler when you turn off the optimization off now and then) with uclibc.

What they used for compiling the pre-compiled drivers is still a mystery

SDK's also include drivers and api depending on the type of product it's for.

Actually it is completly the same. I use firmware from Asus and I use ipkg repository for WL500G. I was also using toolchain for WL500G to compile and run software for my RT-N16.

Here is in more details how to make ipkg to work on RT-N16 on asus firmware: http://www.shcherbyna.com/?p=769&lang=en

[necrolatry]

Has anyone tried to compile GPL sources from Asus for RT-N16? They fail to compile with bizzare warnings and there is no FAQ