Potential problem RT-AC68U (originally TM-AC1900) and WiFi driver 6.37.14.126

RMerlin · Sep 10, 2017

sirwifi said:
I guess I know which way I want it. ENABLED that is

If I remember correctly, @thiggins once mentioned that WMM APSD had to be enabled for full throughput, so your results look normal to me.

RMerlin · Sep 10, 2017

sirwifi said:
Very confidence inspiring. We seem to be all over the place.

Welcome to the world of wifi, where two persons will report exact opposite results. That's why I generally no longer bother investigating reports of "this driver is slower", because for each of them, there's an equal "this driver is faster for me".

Wifi is highly dependent on one's environment, especially the clients used. My tablet's Mediatek can't stay connected to high 5 GHz channels, but I have zero issue with Intel, Qualcomm and Broadcom-based clients.

dlandiss · Sep 10, 2017

RMerlin said:
Welcome to the world of wifi, where two persons will report exact opposite results. That's why I generally no longer bother investigating reports of "this driver is slower", because for each of them, there's an equal "this driver is faster for me".

Wifi is highly dependent on one's environment, especially the clients used. My tablet's Mediatek can't stay connected to high 5 GHz channels, but I have zero issue with Intel, Qualcomm and Broadcom-based clients.

May I add that the results of single tests should not be trusted? WiFi being what it is; with changes due to reflections, local interference, the phase of the moon

, etc; a number of identical tests should be run. Throw out the outliers (best and worst) and average the rest.

If the tests were in a situation needing certification a regular statistical analysis would be needed but the above should suffice in casual situations. Single tests are merely anecdotes.

sirwifi · Sep 10, 2017

I don't think any of us here ran a single test and drew any conclusions from a single run.

FreshJR · Sep 10, 2017

I am assuming there is no windows version of ipref due to hardware level access limitations?

I will test this if I get a portable Linux distro running.

ColinTaylor · Sep 10, 2017

FreshJR said:
I am assuming there is no windows version of ipref due to hardware level access limitations?

https://iperf.fr/iperf-download.php#windows

sirwifi · Sep 10, 2017

A while ago I ran iperf straight on the router, there's a build somewhere, I think from OpenWRT.

jrmwvu04 · Sep 10, 2017

sirwifi said:
A while ago I ran iperf straight on the router, there's a build somewhere, I think from OpenWRT.

iPerf3 3.1.7 is available on entware-ng

sirwifi said:
I don't think any of us here ran a single test and drew any conclusions from a single run.

I thought it was fun to participate in the testing for academic reasons, but ultimately I had already made my mind up a long time ago about some of this stuff. Practical usefulness is really the important metric to me. So like the thing about using a laptop on battery affecting the results of a test - ok, but that's how I'm going to actually use it: on a laptop, that isn't plugged in. So it doesn't matter what results you get if they're not "real world". I think it's a lot like the threads on here about cpu temperatures. People maybe worry too much about the numbers and the specs. And if you want to, that's fine. What matters to me, at the end of the day, is "does it work?" and having done all the tinkering I've done over the years, mine does.

RMerlin · Sep 10, 2017

Running iperf on the router itself is a bad idea however, as just the iperf program itself will put a fairly substantial load on the router's CPU, skewing results.

FreshJR · Sep 10, 2017

You may have a hardware defect, or just the two wifi cards are incompatible. This is ran on TM-AC1900 flashed to 380.67

I got flawless 4 runs in a row a fair distance away from the router (~60ft distance, 4 wall separation, down a story of stairs). I can post router settings if you want because I know i changed two settings (think it was airtime fairness and some WMM setting)

2.4ghz results (far distance)

Code:

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.192, port 50281
[  5] local 192.168.2.194 port 5201 connected to 192.168.2.192 port 63605
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  5.88 MBytes  49.1 Mbits/sec  1.208 ms  0/753 (0%)
[  5]   1.01-2.00   sec  6.76 MBytes  56.8 Mbits/sec  1.707 ms  0/865 (0%)
[  5]   2.00-3.00   sec  6.74 MBytes  56.7 Mbits/sec  1.708 ms  0/863 (0%)
[  5]   3.00-4.00   sec  7.08 MBytes  59.4 Mbits/sec  1.360 ms  0/906 (0%)
[  5]   4.00-5.00   sec  6.53 MBytes  54.9 Mbits/sec  1.184 ms  0/836 (0%)
[  5]   5.00-6.00   sec  6.45 MBytes  54.1 Mbits/sec  1.529 ms  0/826 (0%)
[  5]   6.00-7.00   sec  7.02 MBytes  59.0 Mbits/sec  1.268 ms  0/899 (0%)
[  5]   7.00-8.00   sec  7.05 MBytes  59.0 Mbits/sec  1.535 ms  0/902 (0%)
[  5]   8.00-9.00   sec  6.41 MBytes  53.6 Mbits/sec  1.764 ms  0/820 (0%)
[  5]   9.00-10.00  sec  6.59 MBytes  55.4 Mbits/sec  1.403 ms  0/843 (0%)
[  5]  10.00-10.09  sec   608 KBytes  58.0 Mbits/sec  1.757 ms  0/76 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec  1.757 ms  0/8589 (0%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.192, port 50283
[  5] local 192.168.2.194 port 5201 connected to 192.168.2.192 port 64167
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  5.86 MBytes  48.8 Mbits/sec  1.371 ms  0/750 (0%)
[  5]   1.01-2.00   sec  6.96 MBytes  58.7 Mbits/sec  1.217 ms  0/891 (0%)
[  5]   2.00-3.00   sec  6.80 MBytes  57.0 Mbits/sec  1.660 ms  0/871 (0%)
[  5]   3.00-4.00   sec  6.10 MBytes  51.3 Mbits/sec  1.393 ms  0/781 (0%)
[  5]   4.00-5.00   sec  6.70 MBytes  56.2 Mbits/sec  1.137 ms  0/858 (0%)
[  5]   5.00-6.01   sec  6.80 MBytes  56.6 Mbits/sec  1.212 ms  0/870 (0%)
[  5]   6.01-7.00   sec  6.46 MBytes  54.7 Mbits/sec  1.039 ms  0/827 (0%)
[  5]   7.00-8.00   sec  6.81 MBytes  57.1 Mbits/sec  1.123 ms  0/872 (0%)
[  5]   8.00-9.00   sec  6.87 MBytes  57.4 Mbits/sec  1.329 ms  0/879 (0%)
[  5]   9.00-10.00  sec  6.80 MBytes  57.3 Mbits/sec  1.293 ms  0/870 (0%)
[  5]  10.00-10.09  sec   680 KBytes  65.4 Mbits/sec  1.221 ms  0/85 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec  1.221 ms  0/8554 (0%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.192, port 50295
[  5] local 192.168.2.194 port 5201 connected to 192.168.2.192 port 64168
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  4.65 MBytes  39.0 Mbits/sec  1.986 ms  0/595 (0%)
[  5]   1.00-2.00   sec  5.13 MBytes  43.1 Mbits/sec  1.929 ms  0/657 (0%)
[  5]   2.00-3.00   sec  6.17 MBytes  51.8 Mbits/sec  1.473 ms  0/790 (0%)
[  5]   3.00-4.00   sec  5.84 MBytes  49.0 Mbits/sec  2.189 ms  0/747 (0%)
[  5]   4.00-5.00   sec  5.51 MBytes  46.1 Mbits/sec  1.748 ms  0/705 (0%)
[  5]   5.00-6.00   sec  5.11 MBytes  42.9 Mbits/sec  3.483 ms  0/654 (0%)
[  5]   6.00-7.00   sec  5.34 MBytes  44.8 Mbits/sec  1.845 ms  0/683 (0%)
[  5]   7.00-8.00   sec  5.62 MBytes  47.1 Mbits/sec  1.322 ms  0/719 (0%)
[  5]   8.00-9.00   sec  6.13 MBytes  51.3 Mbits/sec  2.080 ms  0/785 (0%)
[  5]   9.00-10.00  sec  5.96 MBytes  50.2 Mbits/sec  1.507 ms  0/763 (0%)
[  5]  10.00-10.10  sec   584 KBytes  49.4 Mbits/sec  1.810 ms  0/73 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.10  sec  0.00 Bytes  0.00 bits/sec  1.810 ms  0/7171 (0%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.192, port 50297
[  5] local 192.168.2.194 port 5201 connected to 192.168.2.192 port 52449
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  5.41 MBytes  45.4 Mbits/sec  1.330 ms  0/693 (0%)
[  5]   1.00-2.00   sec  6.45 MBytes  54.2 Mbits/sec  1.050 ms  0/826 (0%)
[  5]   2.00-3.00   sec  7.20 MBytes  60.3 Mbits/sec  1.312 ms  0/921 (0%)
[  5]   3.00-4.00   sec  6.74 MBytes  56.6 Mbits/sec  1.371 ms  0/863 (0%)
[  5]   4.00-5.00   sec  5.62 MBytes  47.2 Mbits/sec  1.155 ms  0/720 (0%)
[  5]   5.00-6.00   sec  6.01 MBytes  50.4 Mbits/sec  2.428 ms  0/769 (0%)
[  5]   6.00-7.00   sec  5.19 MBytes  43.5 Mbits/sec  1.547 ms  0/664 (0%)
[  5]   7.00-8.00   sec  6.18 MBytes  51.8 Mbits/sec  1.480 ms  0/791 (0%)
[  5]   8.00-9.00   sec  5.08 MBytes  42.6 Mbits/sec  3.790 ms  0/650 (0%)
[  5]   9.00-10.00  sec  6.79 MBytes  56.9 Mbits/sec  1.335 ms  0/869 (0%)
[  5]  10.00-10.09  sec   608 KBytes  55.9 Mbits/sec  1.291 ms  0/76 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec  1.291 ms  0/7842 (0%)
-----------------------------------------------------------
Server listening on 5201

2.4ghz results (short distance)

Code:

Accepted connection from 192.168.2.192, port 50690
[  5] local 192.168.2.194 port 5201 connected to 192.168.2.192 port 58449
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  11.0 MBytes  92.6 Mbits/sec  0.280 ms  0/1413 (0%)
[  5]   1.00-2.00   sec  12.1 MBytes   102 Mbits/sec  0.139 ms  0/1554 (0%)
[  5]   2.00-3.00   sec  11.4 MBytes  95.5 Mbits/sec  0.263 ms  0/1458 (0%)
[  5]   3.00-4.00   sec  12.1 MBytes   101 Mbits/sec  0.145 ms  0/1547 (0%)
[  5]   4.00-5.00   sec  12.3 MBytes   103 Mbits/sec  0.163 ms  0/1570 (0%)
[  5]   5.00-6.00   sec  11.5 MBytes  96.8 Mbits/sec  0.431 ms  0/1478 (0%)
[  5]   6.00-7.00   sec  12.3 MBytes   103 Mbits/sec  0.418 ms  0/1573 (0%)
[  5]   7.00-8.00   sec  11.4 MBytes  95.6 Mbits/sec  0.174 ms  0/1460 (0%)
[  5]   8.00-9.02   sec  12.1 MBytes   100 Mbits/sec  0.085 ms  0/1552 (0%)
[  5]   9.02-10.00  sec  11.9 MBytes   102 Mbits/sec  0.114 ms  0/1526 (0%)
[  5]  10.00-10.06  sec   912 KBytes   119 Mbits/sec  0.792 ms  0/114 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.792 ms  0/15245 (0%)

As expected when I got closer jitter drops and speeds go up. laptop wifi card is only capable of 300mbps on 2.4ghz at 40mhz bandwidth. I can bump actual throughput to an achievable ~200 out of the 300 link rate.

Iperf settings used: iperf3 -c <host ip> -u -b 100M
Router 2.4ghz settings: https://s26.postimg.org/an7y7gvwp/settings.png
Temps: 50 / 50 / 80 (currently few *C lower than normal)
Hardware rev: Wasn't on serial, where did you read this information?

----------------

But ipref also confirms what I have been experiencing. My 5ghz band is, for lack of a better word, fracked.

On 5ghz I get a BUNCH of these

Code:

iperf3: OUT OF ORDER - incoming packet = 7 and received packet = 8 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 10 and received packet = 11 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 13 and received packet = 19 AND SP = 5

and a variable amount of packet loss 2%-40% depending on distance. I do not want to derail the thread, but is that normal? I think packet loss is normal since I know 5ghz has poor wall penetration, but whats with the out of order packets. Sometimes 0% and no OUT OF ORDER is possible on 5ghz while close but thats not the norm. Doesn't matter to me, I only use 5ghz for large nas file transfers, and its got some insane throughput even with packet loss.

---------------
I know the other firmware gave you good results, but try re screwing the antennas back in. I don't really like ASUS's mechanical connection design. It's a slip plastic ring, so you have to squeeze it really hard to get a firm connection while tightening. If you don't, the plastic ring will just rotate instead of building tension. This connection may be intended to not over tighten, but I like a firmer mechanical connection.

strangeluck · Sep 11, 2017

Not to beat a dead horse, but I re-enabled WMM APSD and ran another series of tests this evening with 0% loss, so I don't think it really has any negative impact on my wifi performance after all.

sirwifi · Sep 11, 2017

@FreshJR that much packet loss on your 5Ghz band is not normal, unless the signal is very poor or there's something else going on.

Also, you're saying you ran your 2.4Ghz tests with -u -b 100M, even for the long distance one? If so, your bandwidth shows a bit under 60Mbps and no packet loss. Where's the rest of 40Mbps then? That should be reported as packet loss.

The summary is also confusing, 0 bytes, 0 bandwidth:

Code:

[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.10  sec  0.00 Bytes  0.00 bits/sec  1.810 ms  0/7171 (0%)

Something is not right with your iperf.

sirwifi · Sep 11, 2017

RMerlin said:
Running iperf on the router itself is a bad idea however, as just the iperf program itself will put a fairly substantial load on the router's CPU, skewing results.

I haven't looked at the CPU use as I'm not sure how reliable it is on ARM, but I really doubt iperf is CPU intensive, what could it possibly do that an 800Mhz CPU couldn't keep up with?

RMerlin · Sep 11, 2017

sirwifi said:
I haven't looked at the CPU use as I'm not sure how reliable it is on ARM, but I really doubt iperf is CPU intensive, what could it possibly do that an 800Mhz CPU couldn't keep up with?

Not saying that the CPU won't be able to keep up with iperf itself, just that running iperf will use a sizable percentage of that CPU, which won't be available for routing. Keep in mind that this CPU is NOT capable of NATing 1 GBps, only around 650 Mbps. That means that with iperf running, your throughput will be even lower than 650 Mbps.

ColinTaylor · Sep 11, 2017

sirwifi said:
Also, you're saying you ran your 2.4Ghz tests with -u -b 100M, even for the long distance one? If so, your bandwidth shows a bit under 60Mbps and no packet loss. Where's the rest of 40Mbps then? That should be reported as packet loss.

Not necessarily. If I run iperf to my ZyXEL access point I see the same sort of packet loss reported as you do. But if I do the same test to my Asus router I don't see the same effect. For example, at long distance (standing at the bottom of my garden!) sending 1000Mbps over a link speed of ~130Mbps, the receive rate is ~29Mbps with no packet loss. So I think that is to do with the interactions between the different hardware.

Code:

C:\Utils\iperf>iperf3 -c micro -u -b 1000m
Connecting to host micro, port 5201
[  4] local 192.168.1.10 port 51210 connected to 192.168.1.50 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  3.76 MBytes  31.4 Mbits/sec  481
[  4]   1.00-2.00   sec  3.40 MBytes  28.6 Mbits/sec  435
[  4]   2.00-3.00   sec  3.74 MBytes  31.4 Mbits/sec  479
[  4]   3.00-4.00   sec  3.66 MBytes  30.7 Mbits/sec  469
[  4]   4.00-5.00   sec  2.81 MBytes  23.6 Mbits/sec  360
[  4]   5.00-6.00   sec  3.01 MBytes  25.2 Mbits/sec  385
[  4]   6.00-7.00   sec  3.12 MBytes  26.2 Mbits/sec  400
[  4]   7.00-8.00   sec  3.49 MBytes  29.4 Mbits/sec  447
[  4]   8.00-9.00   sec  3.55 MBytes  29.8 Mbits/sec  455
[  4]   9.00-10.00  sec  3.71 MBytes  31.2 Mbits/sec  475
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  34.3 MBytes  28.7 Mbits/sec  1.236 ms  0/4386 (0%)
[  4] Sent 4386 datagrams

Code:
The summary is also confusing, 0 bytes, 0 bandwidth:

Code:

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-10.10 sec 0.00 Bytes 0.00 bits/sec 1.810 ms 0/7171 (0%)

That just seems to be a quirk (bug) of the way the iperf server reports the summary line. I see it as well, but the information above it is correct and the summary line on the client is correct.

FreshJR · Sep 11, 2017

sirwifi said:
If so, your bandwidth shows a bit under 60Mbps and no packet loss. Where's the rest of 40Mbps then? That should be reported as packet loss

I understand this logic completely and I have no idea why the missing throughput did not show up as loss when defined transfer was higher than max possible throughput.

I did make sure of the udp flag!

I was just trying to help. I have no Linux machines to test on. This was ipref3 windows version.

Ipref manages to find loss on 5ghz. I will try fringe areas of 2.4ghz.

---

Do you think windows sets up a buffer, so ipref packets go to the buffer when wifi can't keep up. The receiving computer just finds packet loss if it misses a sequential packet. No sequential packets are missed, just the remaining packets never leave the buffer and are destroyed at the end ?

sirwifi · Sep 11, 2017

RMerlin said:
Not saying that the CPU won't be able to keep up with iperf itself, just that running iperf will use a sizable percentage of that CPU, which won't be available for routing. Keep in mind that this CPU is NOT capable of NATing 1 GBps, only around 650 Mbps. That means that with iperf running, your throughput will be even lower than 650 Mbps.

Not doing any NATing tests, it's all LAN if you bind iperf to the LAN interface, when running on the router. But I get your point.

sirwifi · Sep 11, 2017

@ColinTaylor It could be that iperf3 has issues or works differently from iperf2 or platform (e.g. Windows).

FWIW, I'm running "iperf version 2.0.5 (08 Jul 2010) pthreads" on the client (Mac) and server (Linux Mint 17.3/Ubuntu 14.04.5 LTS).

From my past and present tests with iperf I've never seen it not report packet loss when you push past the link bandwidth, this is a first for me. Could be a quirk of either iperf3 or the Windows build or a combination.

sirwifi · Sep 11, 2017

jrmwvu04 said:
iPerf3 3.1.7 is available on entware-ng

I thought it was fun to participate in the testing for academic reasons, but ultimately I had already made my mind up a long time ago about some of this stuff. Practical usefulness is really the important metric to me. So like the thing about using a laptop on battery affecting the results of a test - ok, but that's how I'm going to actually use it: on a laptop, that isn't plugged in. So it doesn't matter what results you get if they're not "real world". I think it's a lot like the threads on here about cpu temperatures. People maybe worry too much about the numbers and the specs. And if you want to, that's fine. What matters to me, at the end of the day, is "does it work?" and having done all the tinkering I've done over the years, mine does.

I think you may be missing the point of these tests. We are not trying to squeeze the last bit of performance out of WiFi. If you read my first post, you will see this all started for me with VOIP issues after I upgraded to the latest firmware, after 3+ yrs of no issues, set it and forget it. That's when I started investigating and found what I found. I fully understand how crappy wireless can be, I'm a firm believer in good wires.

ColinTaylor · Sep 11, 2017

sirwifi said:
From my past and present tests with iperf I've never seen it not report packet loss when you push past the link bandwidth, this is a first for me. Could be a quirk of either iperf3 or the Windows build or a combination.

My point was that with the two test cases everything was the same, same software running on the same hardware. The only thing that changed was in one case I was connecting to the Asus SSID and in the other I was connecting to the ZyXEL SSID. So it can't be iperf or the OS.

Thread starter	Title	Forum	Replies	Date
	RT-BE88U ethernet problem	Asuswrt-Merlin	2	Nov 18, 2024
	Please help me diagnose knotty routing problem	Asuswrt-Merlin	4	Nov 14, 2024
H	Astrill router applet problem.	Asuswrt-Merlin	0	Oct 30, 2024
C	OVPN server setup problem	Asuswrt-Merlin	7	Oct 12, 2024
	RT-AX88U Pro - Merlin Firmware:3004.388.8_2 - WiFi connection problem	Asuswrt-Merlin	11	Oct 3, 2024
G	RT-AC87U wifi flaky connections and network problem on reboot.	Asuswrt-Merlin	3	Sep 27, 2024
C	Weird client VPN problem that just started !	Asuswrt-Merlin	53	Sep 4, 2024
E	RT AX88U problem with update 3004 388-8-1 and 2: loss of internet access	Asuswrt-Merlin	8	Aug 28, 2024
D	Solved 3004.388.8_* LAN clients connection problem	Asuswrt-Merlin	7	Aug 13, 2024
B	Asus - RT-AX88U - USB Application - Network Place (Samba) Share / Cloud Disk - Problem when enabling Allow guest login	Asuswrt-Merlin	4	Jul 29, 2024

Potential problem RT-AC68U (originally TM-AC1900) and WiFi driver 6.37.14.126

Asuswrt-Merlin dev

Asuswrt-Merlin dev

Very Senior Member

Regular Contributor

Very Senior Member

Part of the Furniture

Regular Contributor

Very Senior Member

Asuswrt-Merlin dev

Very Senior Member

Regular Contributor

Regular Contributor

Regular Contributor

Asuswrt-Merlin dev

Part of the Furniture

Very Senior Member

Regular Contributor

Regular Contributor

Regular Contributor

Part of the Furniture

Similar threads

Similar threads

Support SNBForums w/ Amazon

Sign Up For SNBForums Daily Digest