OC200 + EAP245 V3 - wireless speed optimization?
Hi, installed today an OC200 controller plus two EAP245 V3 access points, at home.
Both AP are connected to the router with an ethernet cable.
Latest firmware on everything:
OC200 runs Firmware Version:
1.2.1 Build 20191126 Rel.59455
Controller Version:
3.2.5
Each EAP245 V3 runs Firmware Version:
2.4.0 Build 20200117 Rel. 39932
Now an interesting (maybe not so much?) part: I replaced two older Archer C2600 wireless routers, working strictly as two independent AP.
So on these C2600 routers (AP) I was getting up to 540 Megabit down on both my iPhone and iPad.
On the new EAP245 V3 though I can't get anything above 400-410 Megabit down.
The wired speed in the house is approx 940 down.
Anything in the settings I can change/optimize?
For example, this online review is claiming 855 Megabit down, I can't seem to get anywhere near that speed.
h_t_t_p_s://dongknows.com/tp-link-eap245-v3-omada-poe-access-point-review/
Thanks!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @NorthGraves,
I have a very similar setup (Fios Gigabit, OC200, 2x EAP225V3). I use separate SSID's for 2.4GHz and 5.8GHz -- no band steering, no airtime fairness. I have about 40 devices on my wireless network, many apple products, several Lenovo laptops, and various Nest cams, etc.
Unlike Ethernet, where these days you usually get at least 80-95% of the "rated speed" (e.g. ~900 Mbit over 1 Gigabit), with Wifi there are a number of other factors. Without going into too many technical details, due to overhead, retransmission, payload vs header sizes, etc. real application throughput (e.g. 400-500Mbit/s using a speed test over a 5.8GHz, 80MHz, 2x2 connection) is generally, at best 40-60% of the air link speed.
So, given your Apple device (like mine) which has a 2x2 MIMO 802.11ac radio, it's air link speed will be at most 866 Mbit/s -- given a very strong signal (both from the AP and from your handset back). Even though the EAP245 supports 3x3, since your client does not, it can't use it. So, you can expect to get at most 40-60% of 866 as real, usable throughput.
Now that said, I have notices that I peak out around ~400-450 Mbit/sec, very rarely hitting ~500Mbit/s on my EAP225's when sitting in the same room with them (one iso in my beadroom and one is downstairs in my office). This seems to depend a lot on what speed test I use (SpeedSmart (my favorite), Speedtest (ookla), or Fast (Netlix). For iOS I also like "Wi-Fi SweetSpots" which is not a speed test, but rather displays the air link speed (aka 866) so you can see how it changes as you move away from the AP.
But, you are right. I have seen subtle differences between different AP devices/chipsets. My Verizon FIOS Routers (which also has an AP that I normally disable) is capable of slightly faster 802.11ac 80MHz 2x2 speeds. Using the DFS channel (which it annoys that TP-Link does not support) I can often get 500-550Mbit/sec on speed tests when I am in the same room with it -- of course this is with one single client on its SSID (my iPhone XSM iOS 13.4 and now 13.4.1) on wide open spectrum (DFS), connected to my FIOS with little or no switching latency/overhead.
For me, I prefer the management capabilities of the TP-Link solution, it's resiliency under multiple heavy users, and the ability of my one EAP225 (in my bedroom over MOCA) to failback to Wifi MESH once or twice a year when my MOCA network flakes out (usually when the FIOS router restarts).
So, sorry I couldn't be more help. I, too, wish my EAP's where a littel speeder. But they seem to make up this minor shortfall with capacity and reliability.
I don't have any 3x3 clients to test with. I have an older EAP245V1 that I've retired. I've thought about "upgrading" to the newer EAP245V3's for the hope of better MU-MIMO given 3x3 and the number of clients I have. But the 245's do not currently support MESH (need Beta firmware), and to really get much benefit from MU-MIMO you really need at least 4x4 MIMO on the AP per radio.
But there are a number of advanced users on this board (and TP-Link reps) so hopefully they will chime in with some suggestions/comments.
- Copy Link
- Report Inappropriate Content
Thanks!
By the way, this is what I got before trying to play with settings:
https://www.speedtest.net/result/i/3808241225
So currently I use both 5 and 2.4 on the same (main) SSID, band steering, seamless routing, and mesh (even if it is not supported by the AP yet).
The "funny" part is I tried disabling both 2.4 and 5 on the second AP, and disabling 2.4 on the first one, saved,
leaving only 5 GHz on one AP and standing in front of it...didn't change the results at all.
Tried playing with 802.11ac only - same - no difference.
Tried playing with 20/40/80 Hz settings - same - no difference.
So I guess I'll keep it as is for now, as you can see I can get peak 424, and I am getting stable 300 down pretty much all over the house, which is not bad.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
NorthGraves, unfortunately I have no EAP245 at hand currently, but I can show you some values measured with EAP225 V3.
First of all, what you are measuring with web-based »speed« tests is the throughputs of the Internet uplink, of the web server the test is being run on and of your client system over your wireless LAN. You are not measuring WiFi throughput of an EAP alone.
For example, with EAP225 in 802.11ac-only mode and 80 MHz channel width in the 5 GHz band, I get following result on Ookla's speedtest.net:
That's pretty accurate; in the past I got much worser results with certain Ookla test servers assigned automatically by this speed test, e.g. something like 145 Mbps on one server and 420 Mbps on another one over a 450 Mbps uplink, both tests over Ethernet cable, not WiFi.
But results in today's tests over WiFi and a 1 Gbps uplink still differ by ~100 Mbps depending on the selected test server:
I usually prefer dslreports.com, which has been most accurate in the past, but currently tests fail due to all European test servers being off-line (except their Amsterdam soft-layer server). I don't know the reason why their European servers are off-line, maybe it's related to the lockdown.
So, it often connects to U.S. based servers when I'm measuring and latency is very bad (~150 to 178ms) as are results for my 1 Gbps uplink. This is one of the »better« tests with the Amsterdam server:
My ISP's test shows a weirdness, too:
Now, how can we reliably measure WiFi throughput of an EAP for optimization? Definitely not with web-based »speed« tests.
The right tool for such tasks is iperf, which is the standard tool for all kind of measurements in networks. I use WiFiPerf b/c it shows the Tx rate of the WiFi adapter for wireless tests, which is not displayed in standard iperf. You can download WiFiPerf for free in Apple's app store (AFAIK it's only available for MacOS).
First, we measure TCP/IP throughput to a server in the LAN. This avoids slowdowns caused by the Internet uplink and the web servers as well as the web browser used for testing (right click on image and open image in new tab to enlarge):
We get 610 Mbps to 670 Mbps throughput at a WiFi Tx rate of 867 Mbps for TCP/IP. This corresponds to a protocol overhead of 23% to 30%, which is normal in 802.11ac.
Note also the Noise level; I have several APs here. If I turn them off, the noise level decreases. I did set Tx power of the EAP to 23dBm to minimize interferences.
Now let's try UDP. Note that the graphical representation of WiFiPerf running on the client is of not useful for UDP, since we need to look at the server-side statistics to see the datagram loss. First, we set the send bandwidth for the test to 720 Mbps and achieve following results (note the amount of lost datagrams):
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.178.22, port 62130
[ 5] local 192.168.178.10 port 5201 connected to 192.168.178.22 port 61837
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 84.5 MBytes 709 Mbits/sec 0.114 ms 0/10816 (0%)
[ 5] 1.00-2.00 sec 85.2 MBytes 714 Mbits/sec 0.144 ms 0/10901 (0%)
[ 5] 2.00-3.00 sec 85.2 MBytes 715 Mbits/sec 0.100 ms 0/10904 (0%)
[ 5] 3.00-4.00 sec 85.8 MBytes 719 Mbits/sec 0.113 ms 0/10976 (0%)
[ 5] 4.00-5.00 sec 86.1 MBytes 722 Mbits/sec 0.135 ms 0/11015 (0%)
[ 5] 5.00-6.00 sec 85.5 MBytes 717 Mbits/sec 0.111 ms 0/10945 (0%)
[ 5] 6.00-7.00 sec 83.6 MBytes 702 Mbits/sec 0.113 ms 220/10925 (2%)
[ 5] 7.00-8.00 sec 84.2 MBytes 706 Mbits/sec 0.134 ms 139/10918 (1.3%)
[ 5] 8.00-9.00 sec 83.8 MBytes 703 Mbits/sec 0.144 ms 351/11080 (3.2%)
[ 5] 9.00-10.00 sec 86.2 MBytes 723 Mbits/sec 0.118 ms 0/11031 (0%)
[ 5] 10.00-11.00 sec 86.1 MBytes 722 Mbits/sec 0.125 ms 0/11019 (0%)
[ 5] 11.00-12.00 sec 85.1 MBytes 714 Mbits/sec 0.113 ms 2/10893 (0.018%)
[ 5] 12.00-13.00 sec 84.8 MBytes 711 Mbits/sec 0.128 ms 138/10987 (1.3%)
[ 5] 13.00-14.00 sec 85.7 MBytes 719 Mbits/sec 0.124 ms 35/11002 (0.32%)
[ 5] 14.00-15.00 sec 86.0 MBytes 722 Mbits/sec 0.096 ms 1/11012 (0.0091%)
[ 5] 15.00-16.00 sec 85.7 MBytes 719 Mbits/sec 0.128 ms 0/10974 (0%)
[ 5] 16.00-17.00 sec 86.0 MBytes 721 Mbits/sec 0.151 ms 0/11003 (0%)
[ 5] 17.00-18.00 sec 84.6 MBytes 710 Mbits/sec 0.104 ms 102/10937 (0.93%)
[ 5] 18.00-19.00 sec 85.0 MBytes 713 Mbits/sec 0.142 ms 108/10983 (0.98%)
[ 5] 19.00-20.00 sec 84.2 MBytes 707 Mbits/sec 0.154 ms 224/11008 (2%)
[ 5] 20.00-21.00 sec 85.8 MBytes 720 Mbits/sec 0.138 ms 5/10984 (0.046%)
[ 5] 21.00-22.00 sec 84.6 MBytes 710 Mbits/sec 0.137 ms 138/10969 (1.3%)
[ 5] 22.00-23.00 sec 85.0 MBytes 713 Mbits/sec 0.113 ms 100/10977 (0.91%)
[ 5] 23.00-24.00 sec 85.2 MBytes 715 Mbits/sec 0.162 ms 119/11023 (1.1%)
[ 5] 24.00-25.00 sec 85.9 MBytes 721 Mbits/sec 0.142 ms 1/11001 (0.0091%)
[ 5] 25.00-26.00 sec 83.6 MBytes 701 Mbits/sec 0.150 ms 244/10942 (2.2%)
[ 5] 26.00-27.00 sec 85.2 MBytes 715 Mbits/sec 0.147 ms 115/11018 (1%)
[ 5] 27.00-28.00 sec 84.9 MBytes 712 Mbits/sec 0.131 ms 109/10978 (0.99%)
[ 5] 28.00-29.00 sec 85.1 MBytes 714 Mbits/sec 0.111 ms 105/10997 (0.95%)
[ 5] 29.00-30.00 sec 85.4 MBytes 716 Mbits/sec 0.131 ms 71/11001 (0.65%)
[ 5] 30.00-30.03 sec 2.84 MBytes 699 Mbits/sec 0.154 ms 0/364 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-30.03 sec 2.51 GBytes 719 Mbits/sec 0.154 ms 2327/329583 (0.71%)
Total datagram loss is 0.71%, which might be acceptable for certain applications which implement retransmissions on a higher protocol layer.
Next, we try 700 Mbps send bandwidth:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.178.22, port 62131
[ 5] local 192.168.178.10 port 5201 connected to 192.168.178.22 port 51784
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 83.1 MBytes 697 Mbits/sec 0.157 ms 0/10634 (0%)
[ 5] 1.00-2.00 sec 83.5 MBytes 700 Mbits/sec 0.137 ms 0/10682 (0%)
[ 5] 2.00-3.00 sec 83.4 MBytes 699 Mbits/sec 0.145 ms 0/10673 (0%)
[ 5] 3.00-4.00 sec 83.5 MBytes 700 Mbits/sec 0.107 ms 0/10687 (0%)
[ 5] 4.00-5.00 sec 83.5 MBytes 700 Mbits/sec 0.162 ms 0/10683 (0%)
[ 5] 5.00-6.00 sec 83.5 MBytes 700 Mbits/sec 0.131 ms 0/10682 (0%)
[ 5] 6.00-7.00 sec 83.3 MBytes 699 Mbits/sec 0.135 ms 0/10662 (0%)
[ 5] 7.00-8.00 sec 83.6 MBytes 701 Mbits/sec 0.128 ms 0/10696 (0%)
[ 5] 8.00-9.00 sec 83.5 MBytes 700 Mbits/sec 0.137 ms 0/10684 (0%)
[ 5] 9.00-10.00 sec 83.5 MBytes 700 Mbits/sec 0.160 ms 0/10683 (0%)
[ 5] 10.00-11.00 sec 83.4 MBytes 700 Mbits/sec 0.122 ms 0/10674 (0%)
[ 5] 11.00-12.00 sec 83.5 MBytes 701 Mbits/sec 0.128 ms 0/10692 (0%)
[ 5] 12.00-13.00 sec 83.4 MBytes 699 Mbits/sec 0.125 ms 0/10673 (0%)
[ 5] 13.00-14.00 sec 83.5 MBytes 701 Mbits/sec 0.117 ms 0/10692 (0%)
[ 5] 14.00-15.00 sec 83.5 MBytes 700 Mbits/sec 0.103 ms 0/10682 (0%)
[ 5] 15.00-16.00 sec 83.4 MBytes 700 Mbits/sec 0.110 ms 0/10681 (0%)
[ 5] 16.00-17.00 sec 83.5 MBytes 700 Mbits/sec 0.165 ms 0/10683 (0%)
[ 5] 17.00-18.00 sec 83.3 MBytes 699 Mbits/sec 0.152 ms 0/10666 (0%)
[ 5] 18.00-19.00 sec 83.6 MBytes 701 Mbits/sec 0.122 ms 0/10695 (0%)
[ 5] 19.00-20.00 sec 83.5 MBytes 700 Mbits/sec 0.157 ms 0/10684 (0%)
[ 5] 20.00-21.00 sec 83.4 MBytes 700 Mbits/sec 0.140 ms 0/10681 (0%)
[ 5] 21.00-22.00 sec 83.4 MBytes 700 Mbits/sec 0.131 ms 0/10678 (0%)
[ 5] 22.00-23.00 sec 83.5 MBytes 700 Mbits/sec 0.138 ms 0/10684 (0%)
[ 5] 23.00-24.00 sec 83.3 MBytes 699 Mbits/sec 0.158 ms 0/10661 (0%)
[ 5] 24.00-25.00 sec 83.6 MBytes 701 Mbits/sec 0.148 ms 0/10704 (0%)
[ 5] 25.00-26.00 sec 83.4 MBytes 700 Mbits/sec 0.130 ms 0/10681 (0%)
[ 5] 26.00-27.00 sec 83.4 MBytes 700 Mbits/sec 0.123 ms 0/10679 (0%)
[ 5] 27.00-28.00 sec 83.2 MBytes 698 Mbits/sec 0.118 ms 0/10650 (0%)
[ 5] 28.00-29.00 sec 83.7 MBytes 702 Mbits/sec 0.126 ms 0/10717 (0%)
[ 5] 29.00-30.00 sec 83.4 MBytes 700 Mbits/sec 0.127 ms 0/10680 (0%)
[ 5] 30.00-30.00 sec 208 KBytes 477 Mbits/sec 0.143 ms 0/26 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 2.44 GBytes 700 Mbits/sec 0.143 ms 0/320429 (0%)
That looks good. We have ~20% protocol overhead.
NorthGraves wrote
Tried playing with 802.11ac only - same - no difference.
Tried playing with 20/40/80 Hz settings - same - no difference.
I can't second this. Changing channel width to 40 MHz gives following results for my EAP225:
Unsurprisingly, throughput is cut by half if channel width is reduced to 40 MHz.
Final note: we can't measure »speed« with all those tools since speed of EM waves is always the same: it's nearly speed of light.
What we measure is throughput (WiFi rate) or goodput (data rate). Throughput/goodput depends on bandwidth, which is the theoretical max. throughput we can achieve by using a certain modulation method.
Conclusion: For 802.11ac @80 MHz channel width max. bandwidth is 867 Mbps. Throughput is ~700 Mbps (~19% WiFi protocol overhead) and goodput is ~640 Mbps on average (~8.5% of the WiFi bandwidth = ~7% of total bandwidth for TCP protocol overhead or in other words: ~26% protocol overhead of TCP and WiFi together).
- Copy Link
- Report Inappropriate Content
Thank you, you've been extremely thorough, I am truly impressed.
Three things:
1) To clarify what I meant by:
"Tried playing with 802.11ac only - same - no difference.
Tried playing with 20/40/80 Hz settings - same - no difference."
Default was (and currently is):
802.11a/n/ac mixed for 5 GHz; Channel width 20/40/80 Hz
802.11b/g/n mixed for 2.4 GHz; Channel width 20/40 Hz
Both 2.4 GHz and 5 GHz are ON on both AP
Here's what I meant - I was able to make things WORSE by changing some of those settings, but I wasn't able to make things BETTER by any combination of the above settings.
Example: Pure 802.11ac on, Channel width 80 Hz only, 2.4 GHz turned off completely, second AP turned off completely - same top ~425 Megabit speed.
2) I "assumed" that a gigabit wire-connected AP would easily do more than say 600-700 between itself and the router on the wire, so I (again) assumed the 425 was the WiFi bottleneck, not the wired AP to the router bottleneck. You proved that was a correct assumption.
3) I simply wanted to see the "net" speed from the AP to the client, after all overheards etc lost. That one seems to be ~425 in my case.
- Copy Link
- Report Inappropriate Content
NorthGraves wrote
Default was (and currently is):
802.11a/n/ac mixed for 5 GHz; Channel width 20/40/80 Hz
802.11b/g/n mixed for 2.4 GHz; Channel width 20/40 Hz
Both 2.4 GHz and 5 GHz are ON on both AP
The issue with mixed modes is the SSID beacon: in 802.11b legacy mode the EAP has to send a beacon every then and when with 1 Mbps WiFi rate. To make best use of AirTime available to all APs and clients I always use:
- 802.11n-only mode for the 2.4 GHz band at 20 MHz channel width in overcrowded areas, 40 MHz channel width in rural areas.
- 802.11n/ac-only mode for the 5 GHz band at 20/40/80 MHz channel width for public hotspots, but 80 MHz-only for offices etc.
Lowering Tx power can be useful to minimize interferences if you have many EAPs using the same channel and if the distance between those EAPs is < 15m. In all other cases I would set it to »High«.
Also make sure to mount the EAP at an ideal position: this is the center of the area you want to cover. Inside the 60º angle you should get an excellent signal and best possible throughput. Inside the 74º angle the signal is acceptable, but throughput drops somewhat. Outside this angle throughput drops even more:
2) I "assumed" that a gigabit wire-connected AP would easily do more than say 600-700 between itself and the router on the wire, so I (again) assumed the 425 was the WiFi bottleneck, not the wired AP to the router bottleneck. You proved that was a correct assumption.
Yes. The EAP245 should exceed the values I measured for EAP225, but your wireless client must support it, too.
3) I simply wanted to see the "net" speed from the AP to the client, after all overheards etc lost. That one seems to be ~425 in my case.
iperf resp. WiFiPerf is well suited for that. You would need a wired server or PC running an iperf instance as the server and using a laptop or PC connected wirelessly to the EAP to run the iperf/WiFiPerf client. See https://iperf.fr/ for more information about this measuring tool.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 5837
Replies: 7
Voters 0
No one has voted for it yet.