Jiri is passionate about mobility ranging from Wi-Fi to folding bikes;-) He is a Wi-Fi Technical Solutions Architect at Cisco UK, proud member of the Cisco Live Network Operations Center deployment team, and WLAN Pi development team. If he is not working, he is most likely riding his Brompton bike.
All opinions are my own, not Cisco's.
It is the latest modulation technique that allows the access point and Wi-Fi client to send even more data over the air than ever before. Effectively, it adds 2 new MCS indexes 12 and 13 and unlocks faster data rates.
Achieving it is challenging as it requires very high Signal to Noise Radio (SNR) – that’s very strong signal and low noise. So in practical terms, it is only used quite rarely.
For context, with another client device using Intel BE200 Wi-Fi 7 adapter, I hit MCS 12 with SNR about 60-62 dB. In other words, if my noise floor was -95 dBm, my signal would have to be about -35 dBm.
Does iPhone 16 support it then?
According to the above spec sheet, the maximum Extremely High Throughput (EHT) the iPhone can achieve is MCS 11. 4096-QAM only uses MCS indexes 12 and 13. Check the mcsindex.net site.
So, the answer is no, it doesn’t.
Is it a dealbreaker?
From data rate perspective, even without 4096-QAM, and using 160 MHz wide channel, we are talking 2000+Mbps! Obviously depending on how far you are from the access point.
So I personally can’t complain. I value access to the clean 6 GHz spectrum, low latency and low retransmissions rate over maximum throughput.
My WAN link speed of 900 Mbps is my personal bottleneck and I usually don’t transfer huge amounts of data from the phone.
On a laptop, I can imagine 4096-QAM to deliver much more value when it comes to performing backups for moving very large software image or video files. Having said that, don’t forget that there is 2.5, 5 or 10 Gigabit Ethernet for that.
iPhone 16 supports tri-band Wi-Fi 7 and Multi-Link Operation (MLO). More specifically, the Enhanced Multilink Single‐Radio (EMLSR) mode. The client connects using 2 different Wi-Fi bands, only actively uses 1 of them and listens on both bands simultaneously. Let’s enable it on an access point and verify that it works.
We have a 320 MHz channel configured on the 6 GHz radio. This is for experimental purposes only. Please use narrower channel in production to avoid adjacent channel interference with other 6 GHz access points.
The tri-band SSID is announced in 2.4 GHz, 5 GHz and 6 GHz bands. It is up to the client device to choose the preferred band. MLO-capable Wi-Fi 7 clients can also enable the MLO feature.
Although iPhone 16 supports MLO, the phone itself doesn’t indicate if MLO is active or not. So our only option is to monitor it from the access point’s side. This is a consumer access point and it doesn’t provide a huge amount of detail. I am hoping to retest this with a proper enterprise-grade AP when I can.
Single band at a time
From the Association Request sent by the iPhone to the access point, we can see that it advertises support for only one band at a time.
With the default settings of the TP-Link Deco BE85 Wi-Fi 7 access point in place, the iPhone establishes MLO using 2.4 GHz and 6 GHz. It actively uses 6 GHz. 2.4 GHz is there for backup purposes.
The iPhone uses its 160 MHz wide channel capability and actively pushes all data using the 6 GHz channel 69 as I am trying to demonstrate below using Oscium WiPry Clarity spectrum analyser. Check the “waterfall diagram” that shows the top 160 MHz of the 320 MHz channel being busy processing the data transmission.
The 2.4 GHz link just sits there in the background, unused. Using the same method, I verified that there is no spectrum utilisation whatsoever on the 2.4 GHz channel.
5 GHz and 2.4 GHz EMLSR MLO mode
When we change Preferred Wi-Fi Band setting to 5 GHz, the iPhone establishes 5 GHz active MLO link and 2.4 GHz as backup.
6 GHz and 5 GHz EMLSR MLO mode
Now, how do we force MLO using the two modern bands? For the purposes of the demo, I simply disable 2.4 GHz radio on the access point.
The phone establishes 6 GHz active data connection and uses the 5 GHz band as a backup. How can I be so sure? I watched the spectrum and generated nearly 900 Mbps of data over the wireless link. While the 6 GHz channel shows high utilisation, the 5 GHz channel shows no signs of use.
On the iPhone, we see active channels 69 in the 6 GHz band. That matches what I’ve just seen using the spectrum analyser.
How to trigger MLO band change?
Now, I connect the iPhone using 5 GHz channel. I am going to saturate the channel with other client’s traffic. My hope is that high channel utilisation makes the iPhone stop using the 5 GHz channel and switch to the backup 2.4 GHz channel.
And the result? It correctly detected and reported high channel utilisation, but the MLO band change did not happen.
So channel utilisation on its own did not do the trick for me. Perhaps the algorithm penalises and tries to avoid the 2.4 GHz band which is typically in a much worse condition than 5 GHz? Or high channel utilisation must persist for a longer period of time? Time will tell.
What chipset does it use? To find out we are going to enable Personal Hotspot on the iPhone and see what information we can get from the information elements it broadcasts in its beacons.
As we can see here, iPhone 16 uses Broadcom Wi-Fi 7 chip. That’s about the level of detail we can capture from the beacon frames it sends.
Continue reading
Does the iPhone 16 support Multi-Link Operation? Check this blog post.
All iPhone 16 models support tri-band Wi-Fi 7 as you might have seen here. But what is the maximum channel width they support in the 6 GHz band?
Although my Wi-Fi 7 access point uses 320 MHz wide channel, the maximum 6 GHz channel width iPhone 16 supports is 160 MHz.
Here is the client view of the world.
Spectrum view
I am using Oscium WiPry Clarity 6 GHz spectrum analyser to see the spectrum. When we run a WAN speed tool Speedtest.net (it is not designed to be a Wi-Fi test tool) to generate some traffic here and see how it utilizes the 160 MHz channel.
Outside of that, I also checked the 2.4 GHz channel. There was no activity there. So that proves that only one of the 2 bands involved in MLO is active at a time.
Updated: Apple’s iPhone 16 Wi-Fi specification
New documentation is now available directly from Apple. Note that 160 MHz is the maximum channel width for all models.
You normally won’t use 320 MHz wide channel anyway in Europe
Having said that, at least in Europe, we only have one 320 MHz wide channel available. So by the time you add a second access point you will have to downgrade to 160 MHz channels or narrower. That is to prevent the 2 APs from stepping on each other’s toes and causing adjacent channel interference. No support for 320 MHz channel width on the iPhone is not really a problem.
If you were considering using 320 MHz channels, or if your vendor uses that as a factory default setting, please be a good citizen and don’t.
All iPhone 16 models now support Wi-Fi 7 and come with 2×2 MIMO 2-Spatial Stream radio configuration. But Wi-Fi 7 doesn’t make support of 6 GHz band mandatory. So technically there could be Wi-Fi 7 clients that only support 2.4 GHz and 5 GHz.
Do iPhones 16 support all three 2.4 GHz, 5 GHz and 6 GHz Wi-Fi bands?
I tested a standard non-Pro iPhone 16 model.
It indeed supports all three Wi-Fi bands. Here is a proof of iPhone 16 connected to a Wi-Fi 7 access point using 6 GHz channel 69.
Using the My Wi-Fi Apple Shortcut we can look into another level of detail. In this case the iPhone is using the 802.11be Wi-Fi 7 standard to communicate with the access point.
Association Request
As the iPhone associates to the AP, it announces no support for 320 MHz channel width.
The Realtek RTL8126 chip we are testing today is so far the most suitable for Raspberry Pi 5. It is capable of 5 Gigabit Ethernet at full speed. TCP iperf3 throughput peaks at 4.7 Gbps. It doesn’t overheat. And it doesn’t excessively utilise the Raspberry Pi 5 CPU.
This particular one is sold under the iocrest brand. Like the other boards and adapters there is no increst branding on it and it will likely be sold under various brands. The RTL8126 chip is the key component here.
How did we connect it to the Pi? Via PCIe bus. We breakout the Raspberry Pi 5’s PCIe connector via Pineboards (aka Pineberry Pi) board to M.2 M-key slot. And in that slot we install the iocrest 5 Gigabit Ethernet network adapter – that’s the black M.2 module, plus a PCB with RJ-45 connector on a grey ribbon cable.
Here is how it looks from PCI device perspective.
Performance
It has no problem negotiating full duplex 5 Gigabit Ethernet and filling the interface with traffic fully.
iperf3 with default TCP settings peaks at 4.7 Gbps up and down. More parallel streams don’t improve the result any further. This is in PCIe Gen 3 mode.
Just for the record, if we downgrade PCIe bus to Gen 2 link speeds, we are talking 3.43 Gbps down and 3.31 Gbps up iperf3 TCP throughput-wise.
Thermal footprint
Fully loaded by TCP traffic, I see temperature of 81.2° C (178° F) on the top surface of the RTL8126 chip. Yes, it is on the warmer side, but Raspberry Pi 5 SoC runs quite warm too and it is nowhere near 122° C temperatures I observed on this “hot” 10 Gigabit Ethernet adapter.
By the looks of it, there is no temperature sensor on the PHY so I can’t measure internal temperature.
Linux software support
I happened to have Raspberry Pi OS with 6.8.0-rc7 kernel running on the Raspberry Pi 5. Out of the box, the adapter did not work. iocrest included driver download link pointing to this Chinese website but I am not so sure I want to use that one.
This adapter in PCIe Gen 3 mode draws about 1.5 W in idle, and 2.1 W under full iperf3 load.
Switching the adapter to Gen 2 mode doesn’t make any power savings. I measured 0.1 W less in Gen 2 mode.
The whole setup of Raspberry Pi 5 with fan, Pineboards PCIe adapter, and this 5 GbE adapter in PCIe Gen 3 mode draws about 5.1 Watts in total under full iperf3 load.
Does it work on Windows 11?
Yes, it does. I installed one in Intel NUC 12th generation. It runs at full speed full and Gen 3 x1 mode.
Windows 11 driver (as of May 2024) downloaded automatically via Windows Update only allows this adapter to use 2.5 GbE. To unlock 5 GbE we download driver directly from Realtek’s website and we are all set.
With the adapter inserted in M.2 M-key slot, we won’t be able pop the NUC bottom lid back on. The adapter is just a bit too tall.
Throughput also looks good. I might revisit Windows throughput testing tools at some point. But for now, I take 4.74 Gbps down and 4.42 Gbps up speeds. Increasing number of parallel streams did not improve throughput in any way.
For the record, Jumbo frames seem to be supported but I had no reason to explore this further this time.
Summary
As I mentioned towards the beginning, 5 Gigabit Ethernet based on Realtek RTL8126 chip seems to strike the perfect balance for Raspberry Pi 5. It delivers 4.7 Gbps up and down, doesn’t consume much power, and doesn’t produce excessive amount of heat.
Long-time test will tell how it actually performs but for now I am happy with what I’ve seen.
From driver perspective, I am wondering if the latest Linux kernel supports this chip natively or if I can enable the right kernel module manually.
It is refreshing to be able to test hardware which actually has a product name :) TP-Link TX401 is a 10 Gigabit Ethernet copper PCIe adapter.
How to connect standard PCIe card to Raspberry Pi 5
I am testing on Raspberry Pi 5 and Intel NUC. Both do have an M.2 M-key slot and they won’t take this card natively, will they?
Pineboards (previously known as Pineberry Pi) makes a great PCIe Gen 3 compatible board that breaks out Raspberry Pi 5 PCIe connector to M.2 M-key slot. And from there we can use another adapter – MZHOU M.2 to PCIe 4X Adapter. It allows us to insert a standard size PCIe card into M.2 M-key slot.
The Ethernet adapter is correctly recognised. We just need to build a custom Linux kernel with AQC107 kernel module enabled. Steps by steps instructions are here for your reference. They work for all AQC107 based adapters I’ve tested.
It negotiates 10 Gbps Full duplex link with my switch.
But it only works in PCIe Gen 2 mode on Raspberry Pi 5 in this setup. That means that throughput will be significantly limited to 3.44 Gbps download TCP speed and 3.07 Gbps upload. Using more parallel streams did not help in any way. We are limited by the 4 Gbps throughput of PCIe Gen 2.
I was not able to make PCIe Gen 3 work using this setup. Understandably, high-speed buses don’t like the extra connectors and adapters.
Updated: It wasn’t available back then when I tested this, but Pineboards now sells uPCIty Lite HAT for Raspberry Pi 5 which completely removes the need for the intermediate MZHOU adapter.
How to connect standard PCIe card to Intel NUC
The same M.2 M-key to standard PCIe card adapter works with my Intel NUC 12th Generation.
Windows 11 automatically downloads the latest AQC107 driver using Windows Update.
It negotiates 10 Gbps Full duplex.
The TP-Link card successfully negotiates PCIe Gen 3 x4.
PCIe Gen 3 allows us to achieve TCP throughput of 9.48 Gbps with no effort in the download direction and 9.49 Gbps in the upload. So this card can clearly do 10 Gigabit Ethernet, it just needs PCIe Gen 3 link speed.
No overheating problem
Unlike unbranded Chinese adapters using the same AQC107 chip, this adapter is designed does not overheat. You can read some horror stories about chip temperatures of 122° degree Celsius (252° F) here.
Summary
This adapter achieves nearly 9.5 Gbps of TCP throughput in either direction on Windows if you allow it to use PCIe gen 3 link speed.
Unfortunately, it only negotiated PCIe Gen 2 with Raspberry Pi 5 and Ethernet throughput is limited to about 3.4 Gbps. So for Raspberry Pi, I would recommend a 2.5 GbE adapter which it can fully handle. Alternatively, a 5 GbE adapter. Coming up next. Stay tuned.
It is a good product though with solid cooling. It still produces some heat but that’s a feature of the AQC107 chip. Its advantage is that it keeps the actual system CPU utilisation low even when fully loaded.
Here is the challenge. We have a MacBook Pro M2 and an Intel NUC 12th generation PC running Windows 11. We want to transfer a significant amount of data between the two and potentially sync content of 2 directories. The Mac has no Ethernet adapter.
Solution
Both machines support Thunderbolt 4 and USB4. I happen to have a 0.5 m (1.6 ft) Thunderbolt 4 cable in my tools bag. We connect the two machines back to back. They establish USB4 peer to peer 20/20 Gbps connection, and automatically assign locally significant IP addresses from the 169.254.0.0/16 APIPA range.
Let’s start with the Mac. Head over to System Settings and Network. Select the Thunderbolt Bridge adapter and explore its config.
As far as I can tell, the machines have decided to use USB4. From what Windows network manager is telling us, they negotiated 20/20 Gbps link speed. I expected 40 Gbps but I think I set a wrong expectation in my head. 20 Gbps up and 20 Gbps down full duplex makes up 40 Gbps.
A quick iperf3 test gives us amazing throughput of 16.4 Gbps of TCP traffic from the Mac client to PC server. That’s fast!
By default macOS uses standard MTU size of 1500 Bytes. This is important hold that thought.
In the downstream direction, that is from Windows PC towards the Mac, we “only” get 5.3 Gbps. Windows claims 20/20 Gbps link speed, so what’s wrong?
Yes, we need to bump MTU (Maximum Transmission Unit) size to the maximum value of 9000 Bytes on my Mac. Apparently, Windows defaults to 62000 Bytes MTU on this peer to peer link type, and there is no UI option to change it. But that’s fine for now.
Let’s retest upload speed. Now we are talking. That’s 16.4 Gbps TCP from Mac to PC and 12.8 Gbps from PC to Mac. I am starting the file transfer.
We are not done yet.
Intel NUC and the Windows part
Windows sees this link as a peer to peer USB4 connection.
The two machines negotiated a 20/20 Gbps link. Windows uses 62000 Bytes MTU by default with no obvious UI option to change it. Mac uses 9000 Bytes. MTU mismatch is bad and we should fix that.
Let’s deal with the MTU, and set it to 9000 Bytes on Windows. Same as the Mac.
With matching MTU on both sides of the pipe, we get 15.1 Gbps TCP throughput from Mac to PC, and 13.6 Gbps from PC to Mac. Slightly more symmetrical in both directions.
Summary
I knew Thunderbolt 4 peer to peer connection was possible between 2 Macs but I’ve never tried connecting a Mac to a PC. It works.
Use a Thunderbolt 4 cable, not just a regular “USB-C to USB-C” cable. If there is a Mac involved, increase macOS MTU size to Jumbo 9000 Bytes and match MTU setting on both machines.
The outcome is a peer to peer 20/20 Gbps USB4 link with TCP throughput around 15 Gbps in either direction.