OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

leitec wrote:
davidc502 wrote:

I think we've gone around (in the past) on why the speeds posted above are great whilst everyone else is lagging behind.

Any ideas?

Not any really firm ideas. I am not doing anything fancy here that would explain it. It's a standard image like any other with very basic settings. My desktop and laptop are 5 and 7 years old, respectively, and the NICs are cheap. So, I'd expect anyone who has two 5-year-old machines with Gbe NICs to be able to duplicate this setup and these speeds.

Although I can "max out" the network interface(s) it's still basically working in the limits of what the CPU can push around. It's possible real life factors like latency play a part. I'm not sure I have a correct mental model on how latency would affect such a system.

Are we seeing the difference between wired and wireless?

leitec wrote:

It's possible there are still tweaks here and there to be made. But in the end it's still copying packets around with the CPU. Marvell at one point promised a new implementation of NFP that could potentially be included in the kernel. That would be great news for OpenWrt users, for sure, but it never happened. Updating the existing NFP code to work with new kernel versions is a ridiculous amount of work--not to mention it'd never be accepted into OpenWrt and would be difficult to maintain up-to-date.

I was afraid of that.

leitec wrote:

anything encapsulating IPv4 slows down (PPPoE, VLANs)

I agree on the PPoE part (especially with PPPoE where fragmentation occurs).

leitec wrote:

the problem is CPU-bound in one way or another

That's frustrating considering its an 1.2GHz dual core CPU... But i had the same problem with my old 400Mhz WZR-HP-G300NH who could not handle the ADSL2 -> Fiber upgrade smile That's the main reason i choose to buy a WRT1900AC before OpenWRT was usable on it.

I kept the stock firmware quite a while and the performance dropdown is significant. But if it's the price of a fully customizable device, with a great community of network enthusiast, and an overall great performance. I'll take it as it is. An alternative firmware with pros and cons.

Trying to build a daemon that restarts 5G when necessary.  I've noticed that if I reboot (or run the command "wifi" that will do an down/up on wifi), 5G doesn't come up well enough for my 5G apple devices to connect. (common problem I believe).  I think I am close to getting a hack around this...

* what I'm thinking is: on startup, start this daemon, give it 1 minute or 2 to wait, look for anyone on 5G yet, if not, disable 5G radio (only) wait, enable.  you could kill it at this point, or try again, etc


iwinfo wlan1 assoclist | grep 'No such'  -- this will tell us if the 5G isnt connected to anything (this somewhat assumes you have a present 5G device that is always around (which I do), worse case just turning 5G on/off when no one is connected, so not a big deal either way....


But I cant figure out the syntax to make wlan1.  I believe it will be something like  iw phy phy1 interface add wlan1 type ap but that needs more.  Or something with netifd and /var/run/hostapd-phy1.conf.  I basically want to do whatever luci does when you hit disable and then enable on radio1, cause I have noticed that when I do that, the devices will eventually connect.

    toggle.className = 'cbi-button cbi-button-reset';
else
    toggle.className = 'cbi-button cbi-button-reload';

(Last edited by IvanRaide on 23 Sep 2015, 06:59)

i.trankolov wrote:
IvanRaide wrote:
i.trankolov wrote:

Ooops ... I forgot one file. I've updated the tar file in the link. The missing file is located in /usr/bin/ - you can copy only this file over and test again.

Excellent!  Its working, I already have some points on the graph.  Thanks very much again for fix it.

No problem. I'm glad that I helped.

FYI

Statistics > Collectd Settings > System plugins > Sensors

It crashes when you select Sensors

(Last edited by gufus on 23 Sep 2015, 09:17)

gufus wrote:
i.trankolov wrote:
IvanRaide wrote:

Excellent!  Its working, I already have some points on the graph.  Thanks very much again for fix it.

No problem. I'm glad that I helped.

FYI

Statistics > Collectd Settings > System plugins > Sensors

It crashes when you select Sensors

Did you clean the luci cache (rm -rf /tmp/luci-*) or rebooted after coping the files?

i.trankolov wrote:
gufus wrote:
i.trankolov wrote:

No problem. I'm glad that I helped.

FYI

Statistics > Collectd Settings > System plugins > Sensors

It crashes when you select Sensors

Did you clean the luci cache (rm -rf /tmp/luci-*) or rebooted after coping the files?

I just did a reboot.

gufus wrote:
i.trankolov wrote:
gufus wrote:

FYI

Statistics > Collectd Settings > System plugins > Sensors

It crashes when you select Sensors

Did you clean the luci cache (rm -rf /tmp/luci-*) or rebooted after coping the files?

I just did a reboot.

So it is still crashing?

i.trankolov wrote:
gufus wrote:
i.trankolov wrote:

Did you clean the luci cache (rm -rf /tmp/luci-*) or rebooted after coping the files?

I just did a reboot.

So it is still crashing?

For myself, this is not crashing, (but I did a reboot when I copied the files over).  Has been collecting since I installed it.

IvanRaide wrote:
i.trankolov wrote:
gufus wrote:

I just did a reboot.

So it is still crashing?

For myself, this is not crashing, (but I did a reboot when I copied the files over).  Has been collecting since I installed it.

Same here rebooted also after install. Working fine.

i.trankolov wrote:

[
So it is still crashing?

Thank you very much for your effort! Could you provide your solution to the package maintainer so it is available for everyone (also in the future releases)?

(Last edited by gaga on 23 Sep 2015, 16:18)

i.trankolov wrote:
gufus wrote:
i.trankolov wrote:

Did you clean the luci cache (rm -rf /tmp/luci-*) or rebooted after coping the files?

I just did a reboot.

So it is still crashing?

Nope.

I did it all-over again, it's working now.

Thanks again smile

BTW

Would it be hard to create a collectd for fan speed?

gufus wrote:
i.trankolov wrote:
gufus wrote:

I just did a reboot.

So it is still crashing?

Nope.

I did it all-over again, it's working now.

Thanks again smile

BTW

Would it be hard to create a collectd for fan speed?

I think not. But it is pointless, cause there is no real relation from the number shown in /sys/devices/pwm_fan/hwmon/hwmon0/pwm1 and the actual fan RPM.

i.trankolov wrote:
gufus wrote:
i.trankolov wrote:

So it is still crashing?

Nope.

I did it all-over again, it's working now.

Thanks again smile

BTW

Would it be hard to create a collectd for fan speed?

I think not. But it is pointless, cause there is no real relation from the number shown in /sys/devices/pwm_fan/hwmon/hwmon0/pwm1 and the actual fan RPM.

Ya, your right.

To bad you don't know actual fan RPM.

Cheers...


Mamba
http://www.gypsy-designs.com/fan.pdf
http://www.gypsy-designs.com/fan_info.pdf

(Last edited by gufus on 23 Sep 2015, 18:05)

Chadster766 wrote:
leitec wrote:

Yes, it's routing. My desktop doesn't have an address on the 192.168.2.x/24 network. The laptop (192.168.2.200) doesn't have a route back to 192.168.1.100 (the PC) so it is necessarily NAT.

but I've been seeing these numbers since March or so.

It looks good. I will give it a go to confirm results. This is good news.

I can't confirm these results with CC 15.05 NAT. In fact it's coming in at 380mbps but I'm guessing that due to the eth1 and eth0 tx queue set to 532.

(Last edited by Chadster766 on 23 Sep 2015, 18:15)

I just tried the same setup on a clean flash of CC 15.05 as downloaded from downloads.openwrt.org (i.e. not self-built -- not that it matters). The only change I made was to /etc/config/network, changing lan's IP address to 192.168.1.24/24 and wan's mode to static with IP address 192.168.2.24/24. After /etc/init.d/network restart I ran the test. The PC and laptop configurations were the same. I get the same result as before.

These are really the only two machines I have that I can use for testing. I'll see if I can borrow another laptop or something.

leitec wrote:

I just tried the same setup on a clean flash of CC 15.05 as downloaded from downloads.openwrt.org (i.e. not self-built -- not that it matters). The only change I made was to /etc/config/network, changing lan's IP address to 192.168.1.24/24 and wan's mode to static with IP address 192.168.2.24/24. After /etc/init.d/network restart I ran the test. The PC and laptop configurations were the same. I get the same result as before.

These are really the only two machines I have that I can use for testing. I'll see if I can borrow another laptop or something.

Why is the router LAN IP set to 192.168.1.24 instead of 192.168.1.1?

I have a second interface (on the desktop) and network at 192.168.1.x for all of my router development stuff. I keep 192.168.1.1 free for any devices I'm temporarily working on and change the address once they are up and configured. 1.24 is just the address I picked for the WRT1900AC.

I direct traffic for 192.168.2.x/24 through 192.168.1.24. The WRT1900AC then NATs access from 192.168.1.x to 192.168.2.x (the "WAN" network). The laptop has no default gateway set and can only see 192.168.2.24 ("WAN" IP).

Curiously, I just tested McWRT on the same setup and I only get about 830mbps with a lot more retransmissions per second.

(Last edited by leitec on 23 Sep 2015, 18:42)

leitec wrote:

I have a second interface (on the desktop) and network at 192.168.1.x for all of my router development stuff. I keep 192.168.1.1 free for any devices I'm temporarily working on and change the address once they are up and configured. 1.24 is just the address I picked for the WRT1900AC.

I direct traffic for 192.168.2.x/24 through 192.168.1.24. The WRT1900AC then NATs access from 192.168.1.x to 192.168.2.x (the "WAN" network). The laptop has no default gateway set and can only see 192.168.2.24 ("WAN" IP).

Curiously, I just tested McWRT on the same setup and I only get about 830mbps with a lot more retransmissions per second.

For my test I did complete isolation:

  1. Each computer only had one Ethernet adapter enabled[\*]

  2. One computer directly connected to the WRT1900AC WAN port configured with a Static IP Address[\*]

  3. One computer directly connected to the WRT1900AC LAN port configured DHCP[\*]

  4. WRT1900AC WAN port configured with a Static IP[\*]

  5. iperf3 server ran on WAN port connected computer[\*]

  6. iperf3 client on LAN connected computer[\*]

It's a pain to do it this way.

(Last edited by Chadster766 on 23 Sep 2015, 18:49)

Yes, it is very much a pain to do it that way. I did that at first (same 900+ results, btw) but then switched to this setup for ease. It's still testing the same thing but I can keep it connected all the time.

I honestly don't know why it would not work for you. As I've said I'm not doing anything fancy and have run-of-the-mill equipment. I have done many sanity checks over the months to make sure I am indeed measuring the right thing.

Chadster766 wrote:

I can't confirm these results with CC 15.05 NAT. In fact it's coming in at 380mbps but I'm guessing that due to the eth1 and eth0 tx queue set to 532.

that would cripple you on gig-E

edit: at least with some packet sizes (especially small packets)

(Last edited by dlang on 23 Sep 2015, 19:01)

dlang wrote:
Chadster766 wrote:

I can't confirm these results with CC 15.05 NAT. In fact it's coming in at 380mbps but I'm guessing that due to the eth1 and eth0 tx queue set to 532.

that would cripple you on gig-E

edit: at least with some packet sizes (especially small packets)

AFAIK that's tx queue default for OpenWRT

(Last edited by Chadster766 on 23 Sep 2015, 19:04)

So here's something: I've been repeating these off and on. On most runs it will struggle a bit in the first second and then get up to speed. The tests I have posted here show that. However, every once in a while with iperf3 -R (remote host sends; I suppose that'd be a "download" from WAN) it will struggle but then not go above 500-600mbps for the entirety of the 10 second run. When I repeat, it quickly goes up to the full speed.

Watching the CPU frequency (/sys/devices/system/cpu[01]/cpufreq/scaling_cur_freq) it seems that when that happens one of the cores is running at 600MHz instead of 1200MHz. On "full speed" runs they both go up to 1200MHz. I'd imagine that struggling in the first second is a result of having to do this.

I can't say definitively, but disabling cpufreq scaling (not to be confused with the cpuidle driver) by setting the governor to "performance" so far has eliminated the first second variability and all but eliminated retransmissions. I have not seen any slow runs since doing so. Of course, that has the downside of running the processor harder and thus generating more heat, so you may want to use one of those 3rd party fan scripts that checks more frequently than the 5 minute default cron job does.

The better solution would be to find out why it does this sometimes and not others. But I'd be very curious to see if anyone with a Gb WAN connection sees any improvement doing this.

leitec wrote:

So here's something: I've been repeating these off and on. On most runs it will struggle a bit in the first second and then get up to speed. The tests I have posted here show that. However, every once in a while with iperf3 -R (remote host sends; I suppose that'd be a "download" from WAN) it will struggle but then not go above 500-600mbps for the entirety of the 10 second run. When I repeat, it quickly goes up to the full speed.

Watching the CPU frequency (/sys/devices/system/cpu[01]/cpufreq/scaling_cur_freq) it seems that when that happens one of the cores is running at 600MHz instead of 1200MHz. On "full speed" runs they both go up to 1200MHz. I'd imagine that struggling in the first second is a result of having to do this.

I can't say definitively, but disabling cpufreq scaling (not to be confused with the cpuidle driver) by setting the governor to "performance" so far has eliminated the first second variability and all but eliminated retransmissions. I have not seen any slow runs since doing so. Of course, that has the downside of running the processor harder and thus generating more heat, so you may want to use one of those 3rd party fan scripts that checks more frequently than the 5 minute default cron job does.

The better solution would be to find out why it does this sometimes and not others. But I'd be very curious to see if anyone with a Gb WAN connection sees any improvement doing this.

How do you set "governor to "performance""?

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

leitec wrote:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

**Typo EDIT***

It did not have an effect on throughput:

root@McDev1:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1199000

(Last edited by Chadster766 on 23 Sep 2015, 20:14)