What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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.
 
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.
 
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.
 
I don't think any of us here ran a single test and drew any conclusions from a single run.
 
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.
 
A while ago I ran iperf straight on the router, there's a build somewhere, I think from OpenWRT.
 
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
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.
 
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.
 
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.
 
Last edited:
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.
 
@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.
 
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?
 
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.
 
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


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.
 
Last edited:
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 ?
 
Last edited:
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.
 
@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.
 
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.
 
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.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top