Sure.  But I don't see the point whithout having actual test data, and maye a proposed patch, as input for the discussion.  So far all I've got are unsubstantiated claims.  Which I shouldn't have made at all, of course

But, yes, I do hope to get some time to dig into this.  It's sort of fun, in a very nerdy way...

EDIT: In the hope that someone else will look into this before me: *If* I were to try to do something about how the mwlwifi driver does A-MSDU, then I would look at the iwlwifi implementation in the works.  It uses the kernel'sTSO support to build a super frame, and cares only about the 802.11 framing - leaving all the aggregation logic to the TSO implementaion. It all seems so nice and simple. See the two patches here:
http://www.spinics.net/lists/netdev/msg349446.html

I'm playing with the thought that this is how aggregation should be done in cdc_ncm/cdc_mbim too, and will probably try to implement it there before I get to the mwlwifi driver.  Because I know that there are other, much more capable, programmers looking at mwlwifi.  While I fear that I'm the only one remotely caring about cdc_ncm

(Last edited by bmork on 30 Oct 2015, 10:59)

I don't know what lshw will list.  It's not a tool I'm familiar with. It might be using a static text from som database, or it might be a description from a driver. I have no idea.

But the 7260 family does definitely include an AC card, and has been supported as such in Linux since before it was available on the market.  I bought mine in June 2013.  At that time the firmware wasn't available yet.  But neither were Windows drivers. And a friendly request to Intel resulted in a firmware blob for the Linux driver 24 Jun 2013, still before the Windows drivers were ready

Note that there are 3 major 7260 model variants:
Dual Band Wireless-AC
Dual Band Wireless-N
Wireless-N

Only the first one is AC, of course.  So whether your card supports AC or not is still an open question. See http://ark.intel.com/products/series/75 … 200-Series for details.

FYI, this is the lspci output for my card, with the subsystem PCI ID identifying this as an AC card:

bjorn@nemi:~$ lspci -nnvvs 3:
03:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 63)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
        Physical Slot: 1
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 29
        Region 0: Memory at f0500000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: iwlwifi

This is an early card in mini-PCIE form factor.  There are a number of other device IDs which also are AC.  The easiest way to identify them all is probably to look at the 7260 section of the Linux driver ID table:
https://git.kernel.org/cgit/linux/kerne … drv.c#n274

The name of the config struct attached to each ID will tell you whether it is a 2AC, 2N or N variant.

EDIT:  And if it wasn't obvious: The absolutely safest and easiest way to check actual driver+hardware support in any Linux distro is the same as in OpenWRT: "iw phy0 info"

(Last edited by bmork on 30 Oct 2015, 10:37)

updated /sbin/fan_ctrl.sh since these directories seem to load in a different order in my trunk build.  This should find them dynamically.

#!/bin/sh

WIFI_TEMP_FILE=`find /sys/class/hwmon/hwmon*/ -name temp2_input`
DDR_TEMP_FILE=`echo $WIFI_TEMP_FILE | sed s/temp2/temp1/`
CPU_TEMP_FILE=`find /sys/class/hwmon/hwmon*/ -name temp1_input | grep -v $DDR_TEMP_FILE`

FAN_CTRL=`find /sys/devices -name pwm1`

CPU_TEMP=`cut -c1-2 $CPU_TEMP_FILE`
DDR_TEMP=`cut -c1-2 $DDR_TEMP_FILE`
WIFI_TEMP=`cut -c1-2 $WIFI_TEMP_FILE`

CPU_LOW=85
CPU_HIGH=95
DDR_LOW=65
DDR_HIGH=75
WIFI_LOW=100
WIFI_HIGH=115

if [ "$CPU_TEMP" -ge "$CPU_HIGH" -o "$DDR_TEMP" -ge "$DDR_HIGH" -o "$WIFI_TEMP" -ge "$WIFI_HIGH" ];then
        echo "255" > $FAN_CTRL
elif [ "$CPU_TEMP" -ge "$CPU_LOW" -o "$DDR_TEMP" -ge "$DDR_LOW" -o "$WIFI_TEMP" -ge "$WIFI_LOW" ];then
        echo "100" > $FAN_CTRL
else
        echo "0" > $FAN_CTRL
fi

(Last edited by nyt on 30 Oct 2015, 14:22)

You should probably look at the names to make sure that you are reading from the device you expect.  The device numbering might seem static, but really isn't. The driver probe order might change at any time, causing the numbers to switch around.

root@wrt1900ac-1:~# grep . /sys/class/hwmon/hwmon*/name
/sys/class/hwmon/hwmon0/name:pwmfan
/sys/class/hwmon/hwmon1/name:tmp421
/sys/class/hwmon/hwmon2/name:armada_thermal
root@wrt1900ac-1:~# rmmod pwm-fan
root@wrt1900ac-1:~# rmmod tmp421
root@wrt1900ac-1:~# insmod tmp421
root@wrt1900ac-1:~# insmod pwm-fan
root@wrt1900ac-1:~# grep . /sys/class/hwmon/hwmon*/name
/sys/class/hwmon/hwmon0/name:tmp421
/sys/class/hwmon/hwmon1/name:pwmfan
/sys/class/hwmon/hwmon2/name:armada_thermal

Only one of the devices has temp2_input.  The other is virtual cpu temp.  I'm using that logic to determine, since it was quick and easy.  I could do it by name as well, but this worked.  A better solution would be to write this in C and have it run as a daemon.

first we find the one with temp2_input, which is the wifi temp file
WIFI_TEMP_FILE=`find /sys/class/hwmon/hwmon*/ -name temp2_input`

the ddr temp file is in the same folder as temp1_input
DDR_TEMP_FILE=`echo $WIFI_TEMP_FILE | sed s/temp2/temp1/`

the cpu temp file is the other temp1_input, so we find em both and exclude the ddr temp file.
CPU_TEMP_FILE=`find /sys/class/hwmon/hwmon*/ -name temp1_input | grep -v $DDR_TEMP_FILE`

(Last edited by nyt on 30 Oct 2015, 14:02)

Guys, i need help with debugging this one.

issue:
Downloading from internet over wifi will slowdown to ~15mbit in ~24hrs, until the router is rebooted.
Upload stays fast, and moving data to internal hosts stays fast as well.

please see below picture i've quickly drawn (apologies for terrible handwriting):
click for the picture

so i've tested with iperf3 both up and download speeds between a public 10gbit Iperf server, my laptop (wireless N-300) and a mac mini on the local lan. Every test was done 3 times to get a consistant reading.
Switching to the 2.4ghz connection usually makes the internet connection even slower(??!!)
these are the results (also drawn in the picture above:

Macmini - Internet: 95Mbit Down / 325Mbit up
Laptop - MacMini: 75Mbit Down / 135Mbit up
Laptop - Internet: 15Mbit down / 97Mbit up

So for some reason the routing from internet to the internal lan slows to a crawl after a day, but the other way around stays fast.
Initially i thought this was due to the wireless driver, but further testing between the MacMini and the Laptop shows this is not the case.

The internet connection is a PPPOE connection over a dedicated vlan. The wan port also has a vlan for IPTV, which is routed to the internal lan. All tests were done without the IPTV HW being active.

i do not see any errors in the kernel log, and i'm a bit lost on how to troubleshoot this. I see This issue both on stock 15.05 CC and the latest DD-trunk with the new driver.

Two questions:
1. Does anybody else see this issue?
2. Could some-one help me debug/fix this issue, as i'm a bit lost on the cause and possible fixes.

(Last edited by JohnnySL on 30 Oct 2015, 23:03)

I've seen exactly the same issue on my WRT1900AC-V2 using OpenWRT, both with 15.05 RC3 and with 15.05 final.

At first the router is performing reasonable but some time wireless speed drop to about 15mbit/s download speed, this happens to all clients connected via 5Ghz wifi. A reboot fixes the issue temporarily.

This does not happen when i use DD-WRT.

(Last edited by Nijntje on 30 Oct 2015, 17:57)

interestingly enough, this only happens on the data stream from internet to wireless.
lan to wireless, and internet to lan is pretty much ok.

just have finished iperf testing on the 2.4ghz interface and there i only get 6.5mbit. my 2.4ghz link is only 20mhz wide, so it seems to scale down with the possible bandwith achievable.

could this be somekind of congestion management protocol or buffer going nuts?
ifconfig eth0.6 down/up and disabling/enabling the wireless interfaces doesn't change anything.

To make things even more interesting. Switching to a UDP test gives some suprising results:

./iperf301 -V -i 5 -t 30 -c speedtest.serverius.net -p 5002 -R -u -b 80m
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-5.00   sec  47.9 MBytes  80.3 Mbits/sec  6.081 ms  147/6276 (2.3%)  
[  6]   5.00-10.00  sec  48.8 MBytes  81.9 Mbits/sec  6.080 ms  150/6400 (2.3%)  
[  6]  10.00-15.00  sec  48.8 MBytes  81.9 Mbits/sec  6.120 ms  150/6400 (2.3%)  
[  6]  15.00-20.00  sec  48.8 MBytes  81.9 Mbits/sec  6.067 ms  150/6400 (2.3%)  
[  6]  20.00-25.00  sec  48.8 MBytes  81.9 Mbits/sec  6.043 ms  150/6401 (2.3%)  
[  6]  25.00-30.00  sec  48.8 MBytes  81.9 Mbits/sec  6.064 ms  150/6400 (2.3%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-30.00  sec   300 MBytes  83.9 Mbits/sec  0.689 ms  900/38403 (2.3%)  
[  6] Sent 38403 datagrams
CPU Utilization: local/receiver 2.4% (0.3%u/2.1%s), remote/sender 0.8% (0.1%u/0.7%s)

ok 2.3% packet loss, that is not good, but it is able to send the 80mbit i'm requesting. much better than the earlier seen 15mbit.

I've also just added my old linksys as an AP to the network (connected via lan to the WRT1900AC-V2, and switched my network connection over to there. Here again i see that the TCP iperf3 test is quick from the same device (95mbit instead of 15mbit), and udp shows way better figures without packetloss as well:

./iperf301 -V -i 5 -t 30 -c speedtest.serverius.net -p 5002 -R -u -b 80m
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 30 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-5.00   sec  49.0 MBytes  82.2 Mbits/sec  0.686 ms  0/6275 (0%)  
[  6]   5.00-10.00  sec  50.0 MBytes  83.9 Mbits/sec  5.994 ms  0/6402 (0%)  
[  6]  10.00-15.00  sec  50.0 MBytes  83.9 Mbits/sec  6.022 ms  0/6400 (0%)  
[  6]  15.00-20.00  sec  50.0 MBytes  83.9 Mbits/sec  6.026 ms  0/6400 (0%)  
[  6]  20.00-25.00  sec  50.0 MBytes  83.9 Mbits/sec  6.052 ms  0/6400 (0%)  
[  6]  25.00-30.00  sec  50.0 MBytes  83.9 Mbits/sec  0.684 ms  0/6399 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-30.00  sec   300 MBytes  83.9 Mbits/sec  0.767 ms  0/38403 (0%)  
[  6] Sent 38403 datagrams
CPU Utilization: local/receiver 2.6% (0.3%u/2.3%s), remote/sender 1.7% (0.1%u/1.7%s)

edit:
sysctl -p to reload the sysctl values doesn't fix it
/etc/init.d/network restart doesn't fix it either.

(Last edited by JohnnySL on 30 Oct 2015, 19:08)

I've seen these kind of slowdowns with WIFI before and it usually was caused by WMM WI-FI Powersaving although i haven't got a clue as to what is causing this behavior.

Does this behavior persist with the new MWLWIFI drive?

(Last edited by Nijntje on 30 Oct 2015, 20:12)

yes i'm running the latest wifi driver (10.3.0.12), but i do not think this is wifi related, as lan-to-wifi is fine, but only wan-to-wifi is slow, as explained above.

it might be an issue with the switch or ethernet drivers.

FYI

wifi driver version 10.3.0.12 has been pushed into trunk.
https://dev.openwrt.org/changeset/47279

The image I have made last night has been going strong! I get full wan (180) speeds on my Nexus 6p even through a few walls. Apparently, either I didnt build luci or it did not build correctly [just ssh and opkg update; opkg install luci (luci-ssl if you want)]. The link to it is this: http://tinyurl.com/Lifehacksback-Testing-CC

Enjoy!

Includes:

mwlwifi 10.3.0.12
kmod-fs-xfs (just delete it of you dont need it)
kernel 3.18.21

Suggestions:
Delete fan cron job and sh
Use @gufus deamon fan control

FYI
http://www.dd-wrt.com/phpBB2/viewtopic. … 660#989660

Thanks, I think I'll give it a try... Question: do you know if there are plans to create a new wifi10.3.0.12.bin? So, people can just copy and paste, restart the router and try it out?

It's just I've done so much, and even though I back up changes, there are custom things I've done, and even though I've documented, takes a little while to get it back the way I want to.

So, it's a bit of a pain to install new images... Yeah, I'm a bit lazy, but after coming home from work, the last thing I want to do is work on more IT stuff....

read a couple of pages back: https://forum.openwrt.org/viewtopic.php … 73#p297873

TireMeat quote

"One thing I noticed from some of the folks on the forum, is they're copying the *.ko binary files into lib as if these were windows DLLs -- this code has compile time macros that could generate slightly different object files depending on which menuconfig items chosen (like debug stuff, or if these were built against the same kernel source). This method of trying out drivers is not a good idea -- my suspicion is that the reason the stock 10.3.0.3 is more "stable" is because it was built from branch, and that's what most folks are running."

(Last edited by gufus on 30 Oct 2015, 23:59)

whell all dlls are expecting some links against the kernel anything that works by copy are standalone exes.. so a cli standalone executable wifi driver would be great

(Last edited by makarel on 31 Oct 2015, 02:34)

Excellent....  10.3.0.12 in trunk... 

Firmware Version OpenWrt Designated Driver r47280 / LuCI (git-15.302.35970-25a4457) 
Kernel Version 3.18.21
Local Time Sat Oct 31 10:06:54 2015
Uptime 0h 4m 55s
Load Average 0.04, 0.15, 0.09

root@WRT1900AC-P:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +40.1°C
temp2:        +40.2°C

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +53.0°C

root@WRT1900AC-P:~# strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3"
10.3.0.12
10.3.0.12

Speed better than 10.3.0.3/8 for sure....  Will it be more stable?

Cheers

root@OpenWrt:~# uptime
10:05:39 up 28 min,  load average: 0.06, 0.07, 0.07
root@OpenWrt:~# strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3"
10.3.0.12
10.3.0.12

Wifi seems solid so far, but did notice CPU 0 always running at 50-60%. What would keep the processor up?

Does "top" indicate anything?

I've never found top (on openwrt) to be accurate when identifying which process is using CPU.

The following shows 1% utilization whilst the others are showing 0.

1568     1 root     R     1608   1%   1% /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf

(Last edited by davidc502 on 31 Oct 2015, 16:28)

Is it possible to create a cron job to issue a command to my router (192.168.100.1) to reset itself once a day at 0400? It's a Moto SB6141. Thanks

**Edit**  That's a cable modem...  Nevermind

(Last edited by davidc502 on 31 Oct 2015, 16:52)

Give this a shot.

ps aux --sort -c|head -10

and if you install "procps-watch"

watch -n 1 "ps aux --sort -c|head -10"

CTRL-C to break out