LAN interfaces problems

[PerseoInf]

Hi,

I'm using OpenWrt with the UBNT patch posted in this forum. I'm having a lot of problems with the LAN interfaces:
1) I have tested the WAN port bandwidth with Iperf:

[ 3] 0.0- 2.0 sec 7.08 MBytes 29.7 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 2.0- 4.0 sec 7.04 MBytes 29.5 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 4.0- 6.0 sec 7.02 MBytes 29.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 6.0- 8.0 sec 7.02 MBytes 29.4 Mbits/sec

as you can see the Bandwidth is ~29.5Mbits/sec and not ~100Mbits/sec. Is it normal??

2) the LAN interface next to the WAN port has the same problem. The other port works but it has a very unstable behaviour: if I ping the RS through a cable direct connected to the board I have a packet loss very height!!

Any ideas? Thanks
Andrea

[milank]

Hi,

I am facing similar problems even with latest OpenWrt trunk (r14462). I've compiled it without UBNT patches, I have only used UBNT's .config as a start point.

I have unloaded nearly all modules from the running kernel so as to minimise their impact on network performance (connection tracking and so on).

Local iperf on RS (when I run both "iperf -s" and "iperf -c 127.0.0.1" on the same RS) shows 88 Mbits/s of TCP.

Local to remote through WAN (one iperf running on RS, the other on a much stronger PC) gives only 45 Mbits/s of TCP in either of directions.

Remote to remote through WAN and LAN1 (RS routing between eth0 and eth1) gives 65-72 Mbits/s of TCP in either direction.

Not the dream mechine I have been waiting for so long, but this could be an error elsewhere, because UDP tests are much better:

Routing between WAN (eth0) and LAN1 (eth1) the same way as in the previous test but using "iperf -u -c server_ip -b 200M -i 1 -r" gives us nice 100 Mbit/s:


iperf -u -c 192.168.254.130 -b 200M -i 1 -r
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 122 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.254.130, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 122 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.254.3 port 34007 connected with 192.168.254.130 port 5001
[ 4] 0.0- 1.0 sec 11.4 MBytes 96.0 Mbits/sec
[ 4] 1.0- 2.0 sec 11.4 MBytes 95.7 Mbits/sec
[ 4] 2.0- 3.0 sec 11.4 MBytes 95.2 Mbits/sec
[ 4] 3.0- 4.0 sec 11.4 MBytes 95.5 Mbits/sec
[ 4] 4.0- 5.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 4] 5.0- 6.0 sec 11.4 MBytes 95.6 Mbits/sec
[ 4] 6.0- 7.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 4] 7.0- 8.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 4] 8.0- 9.0 sec 11.4 MBytes 95.3 Mbits/sec
[ 4] 9.0-10.0 sec 11.4 MBytes 96.0 Mbits/sec
[ 4] 0.0-10.0 sec 114 MBytes 95.5 Mbits/sec
[ 4] Sent 81257 datagrams
[ 4] Server Report:
[ 4] 0.0-10.0 sec 114 MBytes 95.2 Mbits/sec 0.068 ms 146/81257 (0.18%)
[ 3] local 192.168.254.3 port 5001 connected with 192.168.254.130 port 42707
[ 3] 0.0- 1.0 sec 11.4 MBytes 95.4 Mbits/sec 0.137 ms 8/ 8122 (0.098%)
[ 3] 1.0- 2.0 sec 11.4 MBytes 95.6 Mbits/sec 0.160 ms 0/ 8129 (0%)
[ 3] 2.0- 3.0 sec 11.4 MBytes 95.4 Mbits/sec 0.186 ms 8/ 8121 (0.099%)
[ 3] 3.0- 4.0 sec 11.4 MBytes 95.5 Mbits/sec 0.220 ms 5/ 8130 (0.062%)
[ 3] 4.0- 5.0 sec 11.4 MBytes 95.6 Mbits/sec 0.201 ms 11/ 8139 (0.14%)
[ 3] 5.0- 6.0 sec 11.4 MBytes 95.5 Mbits/sec 0.326 ms 12/ 8133 (0.15%)
[ 3] 6.0- 7.0 sec 11.4 MBytes 95.6 Mbits/sec 0.245 ms 16/ 8142 (0.2%)
[ 3] 7.0- 8.0 sec 11.4 MBytes 95.5 Mbits/sec 0.153 ms 13/ 8134 (0.16%)
[ 3] 8.0- 9.0 sec 11.4 MBytes 95.6 Mbits/sec 0.121 ms 12/ 8141 (0.15%)
[ 3] 9.0-10.0 sec 11.4 MBytes 95.5 Mbits/sec 0.152 ms 19/ 8141 (0.23%)
[ 3] 0.0-10.0 sec 114 MBytes 95.5 Mbits/sec 0.361 ms 103/81420 (0.13%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order


UNFORTUNATELLY, the test can not be repeated with smaller UDP datagrams, because even with 1000 bytes the RS kernel oopses through TX timeout on either port (only the port is random, the panic is reproducible with each and every test):


iperf -u -c 192.168.254.130 -b 200M -i 1 -r -l 1000
------------------------------------------------------------
WARNING: at net/sched/sch_generic.c:220 ()
NETDEV WATCHDOG: eth0 (ag71xx): transmit timed out
Modules linked in: fuse gpio_buttons input_polldev leds_gpio ohci_hcd ath_pci wd
Call Trace:[<8006f174>] 0x8006f174
[<8006f174>] 0x8006f174
[<80084be4>] 0x80084be4
[<800b41a4>] 0x800b41a4
[<801ae2cc>] 0x801ae2cc
[<800ceee8>] 0x800ceee8
[<800cff64>] 0x800cff64
[<800cf9c8>] 0x800cf9c8
[<801d81e0>] 0x801d81e0
[<801b7a4c>] 0x801b7a4c
[<801ae2cc>] 0x801ae2cc
[<801b2bdc>] 0x801b2bdc
[<801d8350>] 0x801d8350
[<801c5978>] 0x801c5978
[<801ae2cc>] 0x801ae2cc
[<801902c8>] 0x801902c8
[<801c5814>] 0x801c5814
[<8008e524>] 0x8008e524
[<801b73dc>] 0x801b73dc
[<80089a7c>] 0x80089a7c
[<80081a08>] 0x80081a08
[<80068bf8>] 0x80068bf8
[<80089dac>] 0x80089dac
[<80089b34>] 0x80089b34
[<80089e04>] 0x80089e04
[<80099130>] 0x80099130
[<8006bd8c>] 0x8006bd8c
[<8006bd7c>] 0x8006bd7c

---[ end trace 389e622456e02f2c ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 3 seconds..

[PerseoInf]

Thanks a lot for you answer! I will perform more tests about the bandwidth.
Unfortunately the second problem

2) the LAN interface next to the WAN port has the same problem. The other port works but it has a very unstable behaviour: if I ping the RS through a cable direct connected to the board I have a packet loss very height!!

is probably more hard to solve.

Bye bye!
Andrea

[cz_ranger]

This looks interesting - I have been sofar able to get only 25 mbit TCP (iperf, netperf) over ethernet or wireless. Given the fact that wireless in turbo can go up to 60 mbit .... I wonder if it is the absence of UBNT patches that makes the difference.

[UBNT-Mike.Taylor]

Guys,

We sent all the patches for inclusion and they should all be in RC2. When Kamikaze final comes out I am sure it will work with our board unmodified, and we may switch the factory image at that point.

I am investigating the problems with the ag7100 driver in OpenWRT for stability and performance. I'm sure I am not alone in this and it probably will be fixed very quickly as is usually the case with OSS. I appreciate the command line required to produce the crash. I'll try to build the latest Kamikaze code and see if I can reproduce it.

Be sure to check the other posts in the forum and see if you are not being affected by the hardware issue that seems to affect some units.

Thanks,

Mike

[PerseoInf]

Hi Mike,


Note that I haven't reproduced the crash you reported in that thread yet, so I don't know if it is related to the hardware issue. I have hardware to test under both conditions and will let you know.


You can reproduce the kernel oops as described by me in http://lists.openwrt.org/pipermail/openwrt-devel/2009-February/003838.html . This isn't a big problem as reported in http://lists.openwrt.org/pipermail/openwrt-devel/2009-February/003840.html

Is it normal that I can't communicate through the second LAN interfaces? (I have exactly the same behaviour reported in http://forum.ubnt.com/forum/viewtopic.php?p=25153#25153)

How can I test if I have an hardware problem? Could you explain with more details the problems that should I have?

Thanks
Andrea

[milank]

This is a big problem: my RS reboots after the oops caused by huge ethernet traffic. I will try to publis a more detailed description later on the Open-Wrt thread.

I think we should move any discussion of problems that seem to be software-specific to Open-Wrt rather than blaming UBNT for them...

[PerseoInf]

I think we should move any discussion of problems that seem to be software-specific to Open-Wrt rather than blaming UBNT for them...


I think so... but my question is about "probably" and hardware problem. ;-)


Is it normal that I can't communicate through the second LAN interfaces? (I have exactly the same behaviour reported in http://forum.ubnt.com/forum/viewtopic.php?p=25153#25153)


Bye bye
Andrea

[UBNT-Mike.Taylor]

Look at http://ubnt.com/forum/viewtopic.php?t=8334 and also try buildilng the latest OpenWRT code. I believe these issues are fixed in the latest Kamikaze code.

[PerseoInf]

Look at http://ubnt.com/forum/viewtopic.php?t=8334 and also try buildilng the latest OpenWRT code. I believe these issues are fixed in the latest Kamikaze code.

Hi Mike,

good news first.... The throughput of WAN and LAN1 interfaces now it's very high and also the Kernel oops has been fixed.

BUT

The LAN2 interfaces problem is still there and it's always the same with your OpenWrt distro, with the latest OpenWrt trunk (r14584) or with dd-wrt (RS v24 preSP2 - build 10907). Now I thinking that my RouterStation is broken.

Bye bye
Andrea

[UBNT-Mike.Taylor]

PerseoInf,

Sounds like you are bit by the hardware issue described in http://ubnt.com/forum/viewtopic.php?t=8334. Contact support by email and let them know.

Thanks,

Mike

[PerseoInf]

PerseoInf,

Sounds like you are bit by the hardware issue described in http://ubnt.com/forum/viewtopic.php?t=8334. Contact support by email and let them know.

Thanks,

Mike

Thanks Mike I will write to Mike Ford.

Bye bye

[milank]

Works for me!

I've fetched and compiled r14571 (the trunk as of yesterday) and it has solved all the problems I've seen:

- the performance of "internal loopback" TCP iperf is now around 235 Mbit/s
- routing between WAN and LAN1 (eth0 and eth1 in OpenWRT) with all iptables modules unloaded keeps the 100 Mbit ports saturated even with packets of 200 bytes
- no oopses nor crashes anymore

[ogry]

Congratulations, milank

Can you see if USB is working as expected?

How exactly have you done?
If using make from the trunk, can you share you .config's files?



Saludos, OSCAR.