Are we seeing the difference between wired and wireless?

I was afraid of that.

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

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 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, 04:59)

FYI

Statistics > Collectd Settings > System plugins > Sensors

It crashes when you select Sensors

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

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.

Same here rebooted also after install. Working fine.

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, 14:18)

Nope.

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

Thanks again

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, 16:05)

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, 16: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.

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, 16:42)

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, 16: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.

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, 17:01)

AFAIK that's tx queue default for OpenWRT

(Last edited by Chadster766 on 23 Sep 2015, 17: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.

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

**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, 18:14)