EnGenius ECW536 WiFi 7 Access Point Review: Is it too soon for WiFi 7 adoption?

The EnGenius ECW536 is one of the first WiFi 7 access point to enter the market and it’s also one the few to offer some of the most expected features of the new standard out of the box. I am talking about MLO (multi-link operation), a feature which Ubiquiti promises to add at a later date.

And we also get support for the 320MHz channel bandwidth which will work wonders with the 6GHz radio band, there’s Multi-RU Puncturing, as well as support for 4096-QAM. Additionally, the EnGenius ECW536 does have two 10GbE Ethernet ports (multi-Gigabit), supporting both PoE and traditional power connection. As expected, to use power over Ethernet, you do need a robust switch that supports PoE++.

All of this does come at a cost, but that’s to be expected with any early adoption of new technologies. Besides the new WiFi 7 features, the EnGenius ECW536 can be managed and monitored via the Cloud-based platform and yes, most of the security features that could be found on the earlier gen access points are still present here as well. That being said, let’s put the EnGenius ECW536 WiFi 7 access point to the test.

The Design and the Build Quality

I remember when some WiFi 6E APs were released and the manufacturers didn’t really care that much about the size of the device, so they ended up unapologetically huge. But the EnGenius ECW336 was the slimmest of the bunch and I suppose the most stylish as well. It seems that the same philosophy stood behind the development of the EnGenius ECW536 since despite being one of the most powerful access points on the market (at the moment), it’s still fairly slim and with a pleasant design.

The EnGenius ECW536 does measure 9.06 x 9.06 x 1.46 inches (or 23.0 x 23.0 x 3.7cm) and just like the ECW336 and the ECW230S, the top side is made of plastic, but the rear panel is made out of a heavy metallic alloy. Its role is to help dissipate the heat from the main components, but we will see more in the teardown section. To show the status of the device, network and everything that pertains to them, there’s just a single tiny LED positioned on the corner.

Not really a fan of this approach since I prefer the good ol’array of LEDs, but EnGenius has tried to win me over by using RGB. After the connection has been successful and the ECW536 gets Internet access, then the LED will start cycling through different colors. If the Internet connection is disabled, then the LED will start flashing orange. The rest of the top of the case is pretty uneventful, there’s only the faint EnGenius logo in the middle of the matte white finish.

On the side, within the metallic body, there is a Kensington key lock and it seems that the manufacturer decided to leave the bottom middle part for the bracket attachment, moving the ports to the side, within a cut-out area.

Here, you can see the 10GbE Ethernet LAN port which sits next to the 10GbE PoE++ LAN port and yes, both are multi-Gigabit, so you can use 5GbE, 2.5GbE, 1GbE and below connections. It’s great that we see 10GbE access points on the market already and it’s a shame that Ubiquiti missed its chance with the U7 Pro to do the same.
There’s also a recessed Reset button and a Power-in connector. There is no power cable in the package, you need to get your own. But I do need to mention the interesting mounting mechanism that comes with the ECW536.

The Heat Management

To see how well a WiFi 7 access point manages to keep the internal temperature in check, I took out a thermal camera and captured a few photos. As you can see, the plastic top is way cooler than the metallic bottom part and it makes sense considering that its role is to take the heat from the internal components and push it out.

It can get warm to slightly hot depending on the amount of work that the ECW536 needs to do.

EnGenius ECW536 Teardown

I did an entire video of the step-by-step teardown of the EnGenius ECW536 and it’s not really a difficult process. So it’s easy to access the main components and either fix anything that’s needed or just blow out any accumulated dust. Just be aware that the warranty can be voided, depending on the state you’re in.

EnGenius ECW536 vs EVW336 vs ECW220S vs ECW230S

The WiFi Features

The EnGenius ECW536 is a WiFi 7 access point, so there’s a lot to talk about here, but also know that the the Wi-Fi Certified was only introduced last month, so understand that it’s going to take quite a bit before all of the promised features will be supported. Still, the ECW536 is quite generous, offering more than a lot of its peers that have been released in the last few months. There’s support for MLO out of the package which is quite the feat considering that other manufacturer are lagging behind. But why is this feature that important?

It’s a way of keeping the latency incredibly low even when demanding types of applications are being run on multiple connected client devices at the same time. Before, a client device could connect to a single WiFi band, either 2.4GHz or 5GHz (and 6GHz if it was a WiFi 6E AP), but the idea behind the MLO is to make use of multiple radio bands at the same time (it aggregates them), transmitting data across more than one channel. Also know that there are multiple types of MLO implementations.

It can be 2.4GHz + 5GHz, 2.4GHz + 6GHz, 5GHz + 6GHz and it can also be 5GHz + 5GHz (2), the latter essentially demoting the 6GHz band to work as a 5GHz radio band. The EnGenius ECW536 seems to support almost all the configurations with the exception of the last one. Also understand that even if you enable MLO on your radio bands, it doesn’t really mean anything if the wireless adapter that’s installed in the client device does not support it. And at the moment, there are very few adapters released and just one widely available, the Intel BE200.

I actually talked about the way Intel is pretty much gatekeeping the WiFi 7, but does the BE200 support MLO? It does and the supported configs are the same as the EnGenius ECW536 which is excellent. Moving forward, another important feature that’s available with WiFi 7 access points is the Multi-RU Puncturing. It was available even on WiFi 6 devices just pretty much never used. But now it’s mandatory, so what exactly is its purpose? It’s a way to reduce the latency, but to better understand it, let’s first remember the OFDMA, which by the way, it is fully supported here.

The idea behind OFDMA was to use resource units (RUs) to distribute data across multiple client devices at the same time, so there was no need to wait for one packet of data to be transmitted once. But, why not have multiple RUs being transmitted at the same time, so no RUs is left idle? Why not indeed because that’s exactly what happens with WiFi 7 APs, so more data is transmitted at the same time towards more devices in a far more efficient way. But there is an issue, the dreaded interference.

If a portion of an available channel is being held (such as being restricted or blocked in your region), then relying on a granularity of 20MHz, the channel is punctured, allowing it to be partially used for data transmission. Again, all of these features will be more valuable in the near future when most or all client devices will have WiFi 7 adapters.

Multi-client WiFi tests (5GHz)

If you followed the last few reviews of networking hardware, you know that I have included a series of multi-client tests on top of the single-client iperf tests. And the tools that I rely on are the net-hydra and netburn developed by Mr Jim Salter which you can get yourself from Github.com. Why not just post the single-client results that that everyone and they grandma seems to be posting in their reviews? Because it doesn’t reflect real-life performance.

I doubt you’re going to pay good money to simply connect one PC to a wireless router or access point, so I will try to simulate various types of traffic on multiple client devices and take a note of their behavior. Understand that while the main point is not to necessarily to push the EnGenius ECW536 to the limit, I do eventually manage to collapse the connection several times, so I suppose it can be called a stress test as well. These are the client devices that I used for this test and yes, only two are the same, but I assume most people will have some diversity in terms of devices, so it’s a more realistic scenario.

Also, this is the server computer.

• WiFi 6 built-in adapter + 2.5GbE Ethernet port
• 32GB RAM
• NVMe SSD storage
• AMD Ryzen 5 5600xt
• Radeon RX 6800xt.

The EnGenius ECW536 is powered up by a Zyxel XS1930 which has PoE++ 10Gbps ports – the server PC is also equipped with a 10Gbps Ethernet adapter.

4K and 1080p Streaming Test – 5 Client Devices

The first thing that I checked was how the Engenius ECW536 handles the five aforementioned client devices running concurrent simulated 1080p streams (all limited to 1Mbps).

Only two client devices remained underneath 100ms, the WiFi 7 and one WiFi 6 client, so all other will offer a less-than-ideal performance – lots of buffering, but it does depend on the type of streaming. If it’s gaming, this is not good, otherwise, if the video has time to download the packages a few seconds in advance, it should be passable. Not that being so close to 100ms is a stellar performance either, so despite only shaking the bandwidth a tiny bit, we already see some serious spikes in latency. Let’s see if concurrent 4K streaming is better – I updated the throughput to 35Mbps since this is what now Netflix needs for its 4K videos.

The good news is that it’s not that much different than the 1080p streaming which I suppose, it was to be expected since I wasn’t anywhere close to reaching the maximum available bandwidth. But yes, if you intend to stream 4K-level data and you need the latency to be below 30ms, you’re going to have to either limit the number of wireless clients or move a few on cable.
Then again, if it’s streaming Netflix videos, we see the ZimaBoard 832, which is the farthest offering the worst performance. The rest may see some buffering from time to time, but it’s a usable performance.

4K and 1080p Streaming Test + Intense Browsing – 5 Client Devices

Now let’s add some intense browsing in the mix. I tried to simulate how a somewhat lightweight page would behave, where multiple resources are loaded very quickly, creating the illusion that it happens at the same time.

I used 12 x 128KB of data per loaded page and to simulate a somewhat realistic behavior, I also included 500ms of jitter. Yes, it’s more realistic, but it does portray a person compulsively watching a page for a few seconds and then moving on to the next one for about half an hour. All that while 4K streaming is running on all 5 client devices. So it’s not 10 client devices, but two types of traffic simulated on the same machine at the same time.

What I saw is that only the MacBook Pro (WiFi 5) client managed to at least maintain the latency somewhat stable, although still above the ideal. The ZimaBoard is pretty much unusable for 4K streaming, while all other clients will experience frequent buffering even at the 75% mark, which is indeed the highest frequency.

The intense web browsing did suffer a bit as well, with both WiFi 6 laptops going past 1s most of the time and the other clients were a bit better, even if some did occasionally rise above 1s – you can blame it on the CPU, so it can be seen as negligible. Perhaps I went a bit overboard with the 4K streaming, so let’s scale it back to 1080p on all clients, but keeping the intense browsing.

Again, the MacBook Pro is the winner, offering the most stable latency and a decent one as well, at least compared to all other which quickly shut above 200ms. Looking at the intense browsing graph, it seems that the 1080p streaming was sacrificed for as better web navigation experience – nothing that QoS can’t solve.

4K Streaming, Intense Browsing, Download and VoIP Tests

I usually stop here, but some users requested more types of traffic, including simulated download, so I changed things a bit. Two client devices still ran the simulated 4K streaming, two ran intense browsing and one was allowed to use however much bandwidth it wanted to continuously download 10MB files.

The 4K streaming clients are actually performing very well, with a latency below 30ms for the majority of time, but the MacBook Pro did slowly rise above 100ms, so it will see some buffering more often than some users will prefer.

The intense browsing which was also ran on the MacBook Pro essentially failed and so did the Lenovo, so you will navigate the web very, very slowly. What about the download latency? We see values above 400ms most of the time, so yeah, not great. I will work, but it’s not fantastic by any means.

The next test involves two clients that download 10MB files, two intense browsing clients and one streaming 4K. The MacBook Pro client running 4K streaming offers a good performance even if it does have a 5% spike above 100ms and I suppose it also handles the intense browsing somewhat decent, although it does go above what can be seen as acceptable for about 10% of the time. The intense browsing using the Lenovo Y520 just gave up and so did the second Lenovo Y520 laptop for the download traffic. The WiFi 7 client performed a bit better with the simulated downloading traffic – not perfect, but better than expected.

Moving forward, I ran some tests on only 3 client devices and the download and the intense browsing traffic were handled decently well, but the 4K streaming could have been better, quickly passing 100ms, although not by much. Still keeping three client devices, I switched the 4K streaming with VoIP. Also, I changed the 10MB file to 1MB file for the download test.

And the intense browsing latency quickly spiked above reasonable levels, the download latency stayed at about 100ms most of the time which is not great, but not terrible. The VoIP was the unexpectedly pleasant surprise because it was actually great. The last test should be taken as a funny experiment because at the suggestion of a lunatic (you know who you are), I ran a test where I simulated the download of 100x 1MB files across 5 devices at the same time continuously.

As expected, the latency is all over the place, but I also managed to collapse the network entirely, pushing the EnGenius ECW536 offline, requiring an reboot to return to its previous state. I hope this was enough of a stress test.

The Single-client WiFi test (6GHz & 5GHz)

For the single-client tests, the ones that show the big numbers, I had to rely on four client devices. The first one is an older Intel PC where I managed to connect the Intel BE200, the WiFi 7 adapter that doesn’t work that well, but it has been the only available for a long time now (about half a year). The next client is a WiFi 6 laptop (AX200), followed by a WiFi 5 laptop equipped with an Intel 8265 adapter and lastly, there’s the Pixel 2 XL WiFi 5 client device. Besides checking out the throughput based on the distance between the client devices and the access point, I also made sure to check the signal attenuation because as I mentioned many times before, this is a far better way to allow the users to replicate the results that I get.

You can have a different attenuation at 30 feet than me, so how would you know if you will get the same throughput? You can’t unless you take into account the signal attenuation. As I mentioned before, I have had some issues with the WiFi 7 adapter since it refused to go above 1.5Gbps and the range is also less impressive, displaying at about 5 feet away from the AP, a signal attenuation of -54dB. Maybe it’s the antennas, but then again, I tried a couple of BE200 with the same results.

Pages: 1 2