Re: Barrier Breaker can't break 160+ Mbps down

I removed ipv6.ko and rebooted the router.  I confirmed with lsmod that ipv6 was not loaded.  The router still showed a maximum throughput of 162MBits/sec over 300s with iperf.

Re: Barrier Breaker can't break 160+ Mbps down

Hi:

Regarding this thread, we are speaking about speed between WAN and LAN? Not LAN to LAN or WIFI to LAN?
I am thinking in going to BB (I have a WDR3600 V1.5 Stock Firmware) and reading this thread I was in doubt If I should go to BB.
But, if is between WAN and LAN no problem because my Internet have only 14Mbs )

My best regards

128

Re: Barrier Breaker can't break 160+ Mbps down

hobbit_ayla wrote:

Hi:

Regarding this thread, we are speaking about speed between WAN and LAN? Not LAN to LAN or WIFI to LAN?
I am thinking in going to BB (I have a WDR3600 V1.5 Stock Firmware) and reading this thread I was in doubt If I should go to BB.
But, if is between WAN and LAN no problem because my Internet have only 14Mbs )

My best regards

WAN to LAN is the issue

WD MyNet N750 | D-Link DIR-835 | TP-Link TL-WDR3600

Re: Barrier Breaker can't break 160+ Mbps down

Yes, I am testing WAN to LAN, which means the packets are traversing via NAT.

Re: Barrier Breaker can't break 160+ Mbps down

So is anyone closer to finding out what the problem with BB is? yikes Or rather, is any more info from us (users) required? I can get a second router to patch it to BB and test stuff on it.

I want to help make it better smile

131

Re: Barrier Breaker can't break 160+ Mbps down

alphasparc wrote:

Btw enabling Kernel CONFIG_LRO (Large Receive Offload) increases throughput by ~15-20Mbps in short bursts.

How are you turning it on?

132 (edited by alphasparc 2014-10-23 12:31:31)

Re: Barrier Breaker can't break 160+ Mbps down

OpenWRT Chaos Calmer Bleeding Edge GCC 4.9 musl library.
TP-Link WR1043ND V1 Overclock @ 430MHZ
http://i.imgur.com/oK3NyFw.png
Looks good except that not all the software in OpenWRT repo is musl compatible.

Re: Barrier Breaker can't break 160+ Mbps down

Weedy wrote:
alphasparc wrote:

Btw enabling Kernel CONFIG_LRO (Large Receive Offload) increases throughput by ~15-20Mbps in short bursts.

How are you turning it on?

--- ./target/linux/generic/config-3.10 2014-10-19 14:13:12.117461606 +0800
+++ ./target/linux/generic/config-3.10 2014-10-19 13:24:41.823221017 +0800
@@ -1261,7 +1261,7 @@ CONFIG_INET=y
# CONFIG_INET_DIAG is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
-# CONFIG_INET_LRO is not set
+CONFIG_INET_LRO=y
# CONFIG_INET_TCP_DIAG is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_UDP_DIAG is not set

Re: Barrier Breaker can't break 160+ Mbps down

Could someone please supply numbers for the TP-Link WR1043ND V2? I'm considering replacing my TP-Link WR1043ND V1 for a TP-Link WR1043ND V2 due to the faster CPU, more flash and more RAM.

Re: Barrier Breaker can't break 160+ Mbps down

Any news on this? :< the LEDs are terrible at night... and the support for them comes in BB.. :< but it's not worth 120MBit less from my connection speed.

136 (edited by tusc 2014-10-28 17:19:53)

Re: Barrier Breaker can't break 160+ Mbps down

If this helps any this is a test on a WRT1900AC running McWRT 1.0.5 custom build (Attitude Adjustment). Someone asked earlier in this thread for a comparison to MIPs based routers.

This is from Wan to LAN. I have the WAN port on the wrt1900ac connected to my laptop which is running jperf. The iperf server is a Ubuntu host behind the router. Using port forward for port 5001

root@wrt1900ac:/etc/config# uname -a
Linux wrt1900ac 3.2.36 #1 SMP Mon Oct 27 23:23:06 CDT 2014 armv7l GNU/Linux

Using these options for image build:

CONFIG_TARGET_OPTIMIZATION="-Os -pipe -march=armv7-a -mtune=cortex-a9 -mfpu=vfpv3-d16"

http://i.imgur.com/hKSNv3M.png

137 (edited by Vulpix 2014-10-28 17:43:40)

Re: Barrier Breaker can't break 160+ Mbps down

Now test it on BB yikes Also, that speed is kinda monstrous

138

Re: Barrier Breaker can't break 160+ Mbps down

I would like to but BB for the wrt1900ac is unstable right now. sad

Re: Barrier Breaker can't break 160+ Mbps down

I'm guessing no workaround has been found yet?

Re: Barrier Breaker can't break 160+ Mbps down

devinus wrote:

I'm guessing no workaround has been found yet?

Unfortunately no sad

Re: Barrier Breaker can't break 160+ Mbps down

sad I'm sad this is not getting more attention. Is nobody here running a fast connection and a mips device; i.e. nobody bothered by this slowdown?

142 (edited by alphasparc 2014-11-08 01:00:48)

Re: Barrier Breaker can't break 160+ Mbps down

Are you sure this is WAN to LAN?
WAN to LAN does not mean plugging into WAN and LAN port.
It mean a translation from the class C network address 192.168.1.0/24 to another network like 10.1.1.0/24.
Your test seems to indicate LAN to LAN.

tusc wrote:

If this helps any this is a test on a WRT1900AC running McWRT 1.0.5 custom build (Attitude Adjustment). Someone asked earlier in this thread for a comparison to MIPs based routers.

This is from Wan to LAN. I have the WAN port on the wrt1900ac connected to my laptop which is running jperf. The iperf server is a Ubuntu host behind the router. Using port forward for port 5001

root@wrt1900ac:/etc/config# uname -a
Linux wrt1900ac 3.2.36 #1 SMP Mon Oct 27 23:23:06 CDT 2014 armv7l GNU/Linux

Using these options for image build:

CONFIG_TARGET_OPTIMIZATION="-Os -pipe -march=armv7-a -mtune=cortex-a9 -mfpu=vfpv3-d16"

http://i.imgur.com/hKSNv3M.png

143 (edited by tusc 2014-11-08 18:49:51)

Re: Barrier Breaker can't break 160+ Mbps down

alphasparc wrote:

Are you sure this is WAN to LAN?
WAN to LAN does not mean plugging into WAN and LAN port.
It mean a translation from the class C network address 192.168.1.0/24 to another network like 10.1.1.0/24.
Your test seems to indicate LAN to LAN.

I'm positive. Did you not read what I said? I connected the laptop to the WAN port of the router. How could this be LAN to LAN?

I did some further testing. This time LAN to WAN (iperf server on laptop connected to WAN port, iperf client on internal Ubuntu host behind router). It seems WAN to LAN is FASTER as I was getting ~ 850Mbit vs 560Mbit below for LAN to WAN.

http://i.imgur.com/db3MK1C.png

http://i.imgur.com/qXqZfnn.png


Notice the load on one of the router's CPU during LAN to WAN test. It seems TCP and NAT take a toll on the CPU - and perhaps single threaded?:

http://i.imgur.com/3f2uocB.png




Finally, LAN to WAN over UDP - wire speed (load on CPU was negligible).

http://i.imgur.com/SkHn5p4.png

http://i.imgur.com/lAvwapz.png

144 (edited by alphasparc 2014-11-09 01:25:49)

Re: Barrier Breaker can't break 160+ Mbps down

Apparently people don't read what was posted and insist they are right.
If you set the static ip on the wan port and the static ip on the lan port to be on the same network you are NOT testing LAN TO WAN, you are testing LAN to LAN.
Because no translation of the network address needs to take place. The router does not have to rewrite the logical address of the packets. Of course it can process packets at wire speeds.
And also your UDP test is wrong.
You need to set the UDP bandwidth on the Client side before running the test, because UDP does not have the concept of Windows Size, it just fires and forget.
There will be a number on the UDP bandwidth where exceed will cause the server side to drop in the maximium possible throughput, that is the max limit of the UDP NAT performance.

145

Re: Barrier Breaker can't break 160+ Mbps down

alphasparc wrote:

Apparently people don't read what was posted and insist they are right.
If you set the static ip on the wan port and the static ip on the lan port to be on the same network you are NOT testing LAN TO WAN, you are testing LAN to LAN.
Because no translation of the network address needs to take place. The router does not have to rewrite the logical address of the packets. Of course it can process packets at wire speeds.
And also your UDP test is wrong.
You need to set the UDP bandwidth on the Client side before running the test, because UDP does not have the concept of Windows Size, it just fires and forget.
There will be a number on the UDP bandwidth where exceed will cause the server side to drop in the maximium possible throughput, that is the max limit of the UDP NAT performance.

How am I testing LAN to LAN??? Just look at the first screen capture.

Iperf server IP address is 10.1.1.8 and is connected to the WAN port, iperf client is behind the router with an a LAN IP of 192.168.1.111 and connected via one of the 4 LAN PORTS. How are these two address on the same network? How is network address translation not working in this example? Firewall is still up and running and NAT is enabled.

Re: Barrier Breaker can't break 160+ Mbps down

Check your screenshot on post 136
iperf -c 192.168.1.111

147

Re: Barrier Breaker can't break 160+ Mbps down

alphasparc wrote:

Check your screenshot on post 136
iperf -c 192.168.1.111

Yes,

And that was done from the laptop running jperf with a 10.x.x.x IP address attached to the WAN port of the router. Perhaps I didn't show enough screens. I thought I clearly described the network configuration.

148

Re: Barrier Breaker can't break 160+ Mbps down

ifconfig output is verbose, but a lot more descriptive than screenshots. Less work, too.

Try this for UDP client side:

iperf -c <server address> -t 30 -u -b 1G

The client will always report wire speed, it's the numbers from the server that are interesting in UDP tests.

149 (edited by alphasparc 2014-11-19 09:56:15)

Re: Barrier Breaker can't break 160+ Mbps down

Hi I just tried something I should have tried long ago.
I set up NAT as in 10.1.1.0/24 in WAN and use 192.1.1.0/24 in LAN.
Then I telnet into the router and do /etc/init.d/firewall stop
Strangely enough the firewall is still up and NAT is still possible
Performance went up by 100+Mbps!

I did this on a WDR4300 Barrier Breaker Latest.
Before I did /etc/init.d/firewall stop NAT was ~330Mbps
After I did /etc/init.d/firewall stop NAT was ~450Mbps

Re: Barrier Breaker can't break 160+ Mbps down

That's really weird. I remember stopping firewall caused connectivity loss and obviously natting stopped working as well.