2x2 AC Access Point Roundup - Part 2

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

sfx2000

Part of the Furniture
Cool - while I might have some issues with the methodology - I really think this testing is useful at face value - and it would be good to have some very objective data that can be taken back to the vendors (both OEM and Chipset) to improve things.

I hope that the discussion with the OctoScope team is positive, and I think they're the right ones to work with.

Narrowing the scope - focus on the signaling on both the 802.11 and 802.3 (DS side for non-mesh), along with the network and upper layers. Take some of the RF out of the picture, as roaming is more about the jump itself - keep in mind that clients do differ in their triggers - some use RSSI, and some look at BER, and some use both.

Challenge is the client chipset and how it's firmware plays - and Jim rightfully points this out with his client test station - Intel 7260 vs. Realtek on the WUSB-6300.

OctoScope and QC-Atheros chips - I also consider the QCA chips to be a gold-standard when running in monitor mode (along with many other things) - They're very nice to work with, at least with some of them, but the ath9k driver support is first rate in linux considerations.
 

paranoised

Occasional Visitor
Thank you for the insightful write-up and the tests.

I have recently deployed three UAP‑AC‑LITE in a location and was considering whether to go with the same access points for a larger location that would require about 10 access points.

It's good to see that the competition is heating up in this space - perhaps it will put pressure on Ubiquiti to work on the quirks in their platform.
 

Easy Rhino

Regular Contributor
Thanks for trying to test roaming in a standardized way. That's gotta be one of the most infuriating yet least testable features in wifi.
 

thiggins

Mr. Easy
Staff member
Thanks for trying to test roaming in a standardized way. That's gotta be one of the most infuriating yet least testable features in wifi.
Very true. I'm deep into working on testing this, including doing packet captures to see what is really happening.

Look for an article on this within a few weeks.
 

YeOldeStonecat

Very Senior Member
It's *extremely* rare for the DB to get lunched on a commodity server, because it's stored on a journaling filesystem - ext4 or NTFS. For mongo to get lunched there, it needs to be actively being written to at the very moment the system crashes - and it's not a terribly active db..

Not "extremely rare". I've been building them since Ubiquiti first made the Unifi controller multi-tenant..thus made cloud hosted Unifi controllers common place. That was before Ubiquiti became the trendy network hardware brand they are today. The database is pretty busy on cloud hosted controllers...us MSP guys typically have dozens if not over a hundred or more client site networks reporting to them. So that can be thousands of devices. Oh yeah..they're busy. And with the Unifi gateways now doing IDS/IPS and some other UTM-ish features in there...the reporting/logging will really be taking off!

There are differences there, yes, sorta like comparing good battery cache backed RAID controllers against ...el cheap ones, and then pulling the power cord on an Exchange or SQL server a dozen times in a row and praying it keeps booting up fine. However the mongoDB is still VERY touchy with many things, not just I've seen it tank on local (on-prem) regular PCs, virtualized instances, local servers, and up on cloud controller at Amazon, Azure, RackSpace, <pick your favorite host...I haven't had my servers at Linode tank yet..knock on wood>. I've seen it tank on upgrades. I've seen it tank...just because...oh, who the heck knows, it was a full moon that night. Wake up one morning and your Unifi controller was non responsive and basically tanked. Not from a sudden reboot. Granted...getting mongo tanked from an upgrade has not been an issue for the past...quite a few verisons. In the early days of Unifi..especially before Chris B from PFSense took over the Unifi project...the problems are disappearing fast. Only major thing left is how to make it more resistant to rude shutdowns. I put in a feature request a while ago for an auto --repair to run on unexpected shutdowns. Heck..Windows 95 used to auto run scandisk any time it had the power cord pulled.
 

d-m-z

New Around Here
It's nice to see this kind of testing.

Maybe I missed it, but do you mention the firmware versions used? What about the various settings that are available?

On a slightly related note, Ubiquiti just took the wraps off the UAP-nanoHD: https://unifi-nanohd.ubnt.com. Same size as the UAP-AC-Lite, but a lot more powerful.
 

username0475

Regular Contributor
Love the followup on real world deployment.
Thanks JS & TH!

Based on this 2 part article on AP's I was able to incorporate my first AP upstairs into my home network seamlessly- EAP225.
So then I went further last night & added another AP - the outdoor version of the EAP225 - for my garage.
Really only thing I don't like for the outdoor version is that the Cat cable input's location is at the bottom of the box - so it's not in an ideal position to hide cabling.

That said, I do like the performance so far & the TP-Link Omada Controller interface is pleasant to use.

Being a novice to networking - many concepts are still new to me.
Such as: Adopting APs - so it was easy & quick to add a new AP to my site (home) but I am surprised it didn't allow me to uniquely assign a new SSID to this new AP & just onboarded the first AP's set of SSID's.

Not sure if I have to set up a second site only for the garage or somehow isolate this AP to get a unique SSID that isn't also in the upstairs AP.
So while it is advantageous in some respect to have the same set of SSID's on both AP's while roaming throughout the property - it is also not clear which AP I am using either when I am walking abouts.
 

Smashing

New Around Here
Thanks for the review!

I had two EAP330 from TP-LINK, the lack of a working Linux controller (later was released, but too buggy). The lack of support for 802.11k/v/r... As standalone devices are great.
The biggest issue I had was a nasty bug (I reported it and got 0 answers). If the SSID had a password like "Hard Password" containing a blank space and the AP is power cycled, then the AP broadcast the SSID WITHOUT PASSWORD.

I'm testing right now 2 UAP-AC-LITE with the controller in Docker, it's a nice UI and simple to use, but I had my concerns. I chose this AP for the price and because 3x3 won't be used, spreading a few AC-LITE instead a powerful one. I have to deal with power settings and placing to achieve proper roaming (802.11r). Aiming to good roaming and having devices far away is harder than I thought.

About performance, I thought the AC-LITE would perform better for single client and your review just ratified my concerns. Instead the nano-hd with AC wave2 and MU-MIMO looks very promising.
 

Jim Salter

Regular Contributor
Not sure if I have to set up a second site only for the garage or somehow isolate this AP to get a unique SSID that isn't also in the upstairs AP.
So while it is advantageous in some respect to have the same set of SSID's on both AP's while roaming throughout the property - it is also not clear which AP I am using either when I am walking abouts.

Poke around in the controller; basically you can set up different AP groups and decide which APs go in them. I don't still have on Omada controller running, so I can't really walk you through it, but I definitely saw the options in there.

With that said, are you sure you want to do that? Roaming is way less of a PITA than manually joining a separate SSID, in my opinion. And if you really want to know which AP you're connected to, you can check your interface to see what BSSID it associated with, or - on an android phone - use Wifi Analyzer to see which BSSID you're associated with. (Of course, you do have to know which BSSID belongs to which AP for that to help...)
 

Jim Salter

Regular Contributor
Thanks for the review!

I had two EAP330 from TP-LINK, the lack of a working Linux controller (later was released, but too buggy).

I set up Omada on both a Windows laptop and an Ubuntu VM; both worked fine for me, for what that's worth.
 

umarmung

Senior Member
For a single client iperf3/iperf2 test of a 2x2 router, what would be a practical peak 5GHz performance WAN-WLAN? Does UDP throughput matter at all for WiFi throughput testing? Is it worth testing bidirectional (--dualtest under iperf2) for WiFi since its a shared medium?

I am trying to understand how a typical consumer can run a basic throughput test for WiFi routers and compare it to your article, assuming they have a powerful enough client.

Thanks for your thorough testing!
 
Last edited:

Jim Salter

Regular Contributor
There's not really a 1:1 comparison between a single iperf run and what I'm doing; my tests hit higher in the stack than layer 1 (which is the majority of what iperf tests).
You'll also end up testing your own NIC as much as you do the access point or router; if you don't have a baseline to compare it with, you can get misled pretty easily that way.
With all that said... I generally expect to see somewhere between 180-220 Mbps on a single STA iperf3 run at very short range under ideal conditions with 2x2 hardware on both sides. It's possible to get 250-280 Mbps, on a fair day with a stiff breeze, but the difference there isn't going to matter much; it gets overwhelmed in real use very rapidly by longer range, variations in firmware, etc (which is why I do the kind of testing I do).

Note that this assumes that one end of your iperf3 run is wired. If both client and server are connected wirelessly, multiply those numbers by 0.4 - at best.

Also experiment with both the standard invocation of iperf3 -c and iperf3 -Rc (reverse direction). The "normal" direction for an iperf3 run is to upload from client to server; iperf3 -Rc downloads from server to client instead. What you'll discover is that most wifi STAs have a really strong download bias; they'll perform much better at almost any range when downloading data than when uploading it. You'll have to decide for yourself which is more important to you (and figure out the difference between your client sucking at upload vs your router/AP sucking at receiving your client's uploads).
 

speedlever

Regular Contributor
There's not really a 1:1 comparison between a single iperf run and what I'm doing; my tests hit higher in the stack than layer 1 (which is the majority of what iperf tests).
You'll also end up testing your own NIC as much as you do the access point or router; if you don't have a baseline to compare it with, you can get misled pretty easily that way.
With all that said... I generally expect to see somewhere between 180-220 Mbps on a single STA iperf3 run at very short range under ideal conditions with 2x2 hardware on both sides. It's possible to get 250-280 Mbps, on a fair day with a stiff breeze, but the difference there isn't going to matter much; it gets overwhelmed in real use very rapidly by longer range, variations in firmware, etc (which is why I do the kind of testing I do).

Note that this assumes that one end of your iperf3 run is wired. If both client and server are connected wirelessly, multiply those numbers by 0.4 - at best.

Also experiment with both the standard invocation of iperf3 -c and iperf3 -Rc (reverse direction). The "normal" direction for an iperf3 run is to upload from client to server; iperf3 -Rc downloads from server to client instead. What you'll discover is that most wifi STAs have a really strong download bias; they'll perform much better at almost any range when downloading data than when uploading it. You'll have to decide for yourself which is more important to you (and figure out the difference between your client sucking at upload vs your router/AP sucking at receiving your client's uploads).

That's interesting and I didn't realize that about the d/l bias. OTOH, I've observed my iPad Pro (2016) seems to have an upload bias and typically tests faster in uploads than downloads. Go figure.
 

Narmad

New Around Here
Hi,
I've seen your net-burn article and I've few queries on it please help me by answering.
1.what is the content that is in the file 1M.bin which is being used to run the 4kstream?
2. Is there any procedure to generate the bin files for different access categories?

Thanks,
Narmad
 

Jim Salter

Regular Contributor
Hi,
I've seen your net-burn article and I've few queries on it please help me by answering.
1.what is the content that is in the file 1M.bin which is being used to run the 4kstream?
2. Is there any procedure to generate the bin files for different access categories?

Thanks,
Narmad

Random binary data, incompressible.

dd if=/dev/urandom bs=1M count=1 of=1M.bin
 

sfx2000

Part of the Furniture
Random binary data, incompressible.

dd if=/dev/urandom bs=1M count=1 of=1M.bin

$ dd if=/dev/urandom of=1GB.img bs=512K count=2000

Pretty much same thing - to confirm that the file is incompressible,...

$ gzip 1GB.img

File size between the two should be similar…
 

pbc

Regular Contributor
The review comments on the EAP225 as "doesn't support 802.11k,v, or r. I found roaming with the EAP-225s was passable, but not world class. "

Looks like the new EAP225v3 does, as there are "fast roaming" options to "enable 11k/v capable clients to have improved fast roaming...".

Looks like there is a setting called "force-disassociation" which, if enabled, both issues a suggestion to a device that is receiving a weak signal that there is a better signal available and apparently then forces the device to move to the new AP. If disabled, it only issues the suggestion.

Would it be recommended to turn this on where I have several "older" devices (ipads, nexus 7, laptops, etc) that are not 11k/v capable?
 

Jim Salter

Regular Contributor
The review comments on the EAP225 as "doesn't support 802.11k,v, or r. I found roaming with the EAP-225s was passable, but not world class. "

Looks like the new EAP225v3 does, as there are "fast roaming" options to "enable 11k/v capable clients to have improved fast roaming...".

Looks like there is a setting called "force-disassociation" which, if enabled, both issues a suggestion to a device that is receiving a weak signal that there is a better signal available and apparently then forces the device to move to the new AP. If disabled, it only issues the suggestion.

Would it be recommended to turn this on where I have several "older" devices (ipads, nexus 7, laptops, etc) that are not 11k/v capable?

In my experience, this methodology (which ubiquiti also uses) works fine with everything but iPads; iPads have a distressing tendency to just stay disconnected and sit there like idiots until you manually go back into settings, WiFi settings, then click your network (which has a full strength signal icon!) and TELL it to connect again.

Still, like Tim said... Won't know for sure until you try it. Worst case scenario, you don't like it because you have some devices that behave like I just described, so you then disable it again. No biggie.
 

Narmad

New Around Here
Random binary data, incompressible.

dd if=/dev/urandom bs=1M count=1 of=1M.bin

Hi Jim Salter,
Thanks for your response.
I have few queries as listed below. Please help answering.

1. When, I'm trying to featch 1GB data file through netburn after some time, I see the below error.
"Out of memory". Have you ever faced the same issue please confirm?

2. I have limited my network speed to 58 Mbps and initialized netburn to fetch the data using default data rate.
Surprisingly, my throughput is shown as 85 Mbps in netburn stats. Is this an expected behavior?

Thanks,
Narmad
 

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