Jay's some notes

免责申明：本文翻译自 smartnetbuilder 系列 OFDMA 测试文档，建议直接查看原文。What’s Missing From Your Wi-Fi 6 Router? OFDMA、Does OFDMA Really Work? Part 1、Does OFDMA Really Work? Part 2 。侵权立删，文中测试结论均为原作者结论。

你的 Wi-Fi 6 路由器缺少什么？ OFDMA

介绍

OFDMA 频谱图来源：Gjermund Raaen

我感觉自去年以来我一直在等待。

随着 2018 年的结束，广告支持的崩溃迫使我转向付费咨询。尽管这对我在财务上更有利，但主要关注咨询工作意味着在 2019 年几乎没有发布任何关于 SmallNetBuilder 的产品评论。

我一直在尽力改变这一点。但在努力制定新的 Wi-Fi 测试方法以替代之前侧重速度测试，进而转向以测量 Wi-Fi 产品的质量、稳健性和效率时，我一直遇到障碍。

在完成了 octoScope 平台上的TR-398 Wi-Fi 性能测试套件的自动化后，我一直试图证明 OFDMA，这是 Wi-Fi 6 的一个关键特性，可以产生更高的总吞吐量。简而言之：启用 OFDMA 后，我看到了更高的总吞吐量，但增益是高度可变的。

OFDMA 开始看起来很像 MU-MIMO。

正如我在Wi-Fi 6 性能汇总：测试了五台路由器中指出的，测试 OFDMA 的主要障碍之一是迄今市场上的大多数消费级 Wi-Fi 6 产品都没有启用 OFDMA。一次又一次，我被告知新的启用 OFDMA 的固件将在一个月左右发布，但一个月过去了，固件并未更新。在没有要测试的东西时，很难制定测试方法。

截至 2019 年底，美国有四台启用 OFDMA 的 Wi-Fi 6 路由器，如表 1 所示。这是在几乎宣布了几十个 Wi-Fi 6 路由器或网状系统之中的情况。

表1：OFDMA 支持摘要

表1中的 验证 列表示我已看到产品实际传输 HE-MU 数据帧，这是 OFDMA 操作所必需的。对于其他产品，您需要相信制造商的话，尽管我不建议这样做。因为 Wi-Fi 6 认证要求在两个频段上都支持下行（DL）和上行（UL）OFDMA，并不保证您实际购买的路由器上将启用 OFDMA。

例如，ASUS RT-AX88U。ASUS 首先在去年八月左右发布了一个测试版固件，启用了5 GHz 的 DL OFDMA。然后，今年十一月，ASUS 宣布路由器现在已获得了 Wi-Fi 6 认证。然而，一周左右后发布了更新的固件，但没有为 2.4 GHz 无线电启用OFDMA。ASUS 解释说这是与“传统”设备的兼容性问题。

因此，Wi-Fi 6 认证也不能保证完全启用 OFDMA。而且，像160 MHz的信道宽度、DL（AX）MU-MIMO、目标唤醒时间（TWT）和许多与 OFDMA 相关的功能都是可选的 Wi-Fi 6 认证，如下所示在Wi-Fi认证产品查找器中的搜索过滤器所示。

Wi-Fi 6 认证选项

什么阻碍了 Wi-Fi 6 的发展？

所以我们进入了大规模过渡到 Wi-Fi 6 的第二年，高价位的顶级路由器仍在发货，但没有支持（或对支持的保证）关键的 Wi-Fi 6 特性。然而，情况在客户端方面不同，那里没有缺乏支持 OFDMA 的设备正在寻找与其合作的 AP 和路由器。

Samsung Galaxy S10 系列在 Wi-Fi 6 路由器上架后不久开始发货。Intel 为笔记本电脑准备了 AX200 M.2 格式的网卡。甚至 Apple 也相对及时地发布了支持 AX 的 iPhone 11，尽管比 Samsung 慢了大约一年。

就我看到的数据包捕获情况来看，所有这些设备都支持 OFDMA 和 DL AX MU-MIMO。因此，障碍显然存在于路由器/AP 方面。为什么呢？

答案是为 AP 空时调度程序编写代码的人们面临着极为艰巨的任务。在过去，调度程序所要做的一切是使用像轮询这样的简单方法发送数据包。然后在 11n 中出现了数据包聚合，而在 11ac 中更是如此，这意味着数据包不会立即发送出去，而是排队并组合成更大的帧。AC MU-MIMO 进一步复杂化了问题，要求决定何时以何种方式保留数据包并使用 MU-MIMO 波束成形同时传输它们。

现在，AX 调度程序具备了以前的所有方法，再加上 OFDMA。OFDMA 是一种像 MU-MIMO 一样的同时传输方法。但与使用时域（相位角）中的波束成形技术不同，OFDMA 是在频域中运行的，将单个 20、40、80 或 160 MHz 信道分成子信道，称为 RUs（资源单元）。这些 RUs 中的每一个都可以分配给 AX 设备（STA），通常在它们关联时进行分配。

要进一步复杂化调度程序的任务，OFDMA 也在上行方向上工作。因此，调度程序还必须决定是否要接收来自多个 STAs 的数据。UL OFDMA 需要 AP 和 STA 之间的精确同步，这显然并不容易。在真实世界中是否足够可靠，以提供 OFDMA 所承诺的更高带宽效率和更低的延迟，还有待确定。

当然，所有这些决策必须针对每次传输机会（TXOP）进行。正如我所说，这是复杂的东西。

更多关于 RUs 的信息

由于 RUs 是 OFDMA 的核心，因此值得仔细查看。RUs 分为六种不同的信道宽度，每种宽度支持每流的最大数据/链路速率。下表摘自 IEEE 802.11ax 草案规范，显示了每种信道宽度支持的最大 RU 数。

20 MHz 带宽 RU 位置（来自 IEEE 草案 802.11ax）

下图显示了如何将 20 MHz 宽的信道分割成不同的 RU 宽度。RU 越宽，其数据/链路速率越高，可用的就越少。换句话说，如果 AP 希望将更多 STAs 塞进一个 OFDMA 帧中，那么每个 STA 的数据速率就会更低。

需要注意的是，不是所有的 RU 都必须相同。假设 20 MHz 信道宽度，一个帧可以有四个 STAs 使用 26 stone RU，一个 STA 使用 106 tone RU。此分配可以是动态的，因此下一个帧可以使所有五个 STAs 使用 26 tone RU。AP 通过在 STAs 关联时分配给每个 STA 一个 AID（关联 ID）来跟踪哪个 STA 获得了哪个 RU。

20 MHz 带宽 RU 位置（来自 IEEE 草案 802.11ax）

需要注意的是，RU 的宽度不会随着 Wi-Fi 信道宽度的增加而改变。随着更宽的信道，支持更多的 RU，如下图所示。较宽的信道还会增加两种 RU 宽度；只有在 40 和 80 MHz 信道宽度时才支持 484 tone RU，最大值 996 tone RU 需要 80 MHz 宽的信道。

不同信道宽度中的 RUs（来自 IEEE 草案 802.11ax）

可以增加 RU 的吞吐量的因素是空间流的数量。因为大多数 STAs 都是双流，让我们看一下 MCS 表（显示了我们熟知的 26 tone RU 的数据/链路速率，具有两个流）。对于单流，将数据速率值减半。

26 tone RU，2 流 MCS 表（来自 IEEE 草案 802.11ax）

这个表格突出了 OFDMA 中固有的权衡的现实。为了支持单帧中的最多 STA 数，每个 STA 能够获得的最高数据速率接近 30 Mbps。但由于这是一个 MCS 表，这个数字实际上是链路速率，实际交付的数据速率更低。在看到 11ax 可以支持数百个同时客户端的说法时，请记住这一点。

那么在一个双流 80 MHz 信道中支持的单个 996 tone RU 提供了多少数据速率？表 27-97（未显示）给出了 1201 Mbps。这也是 AX 非 OFDMA 80 MHz 信道支持的最大数据速率。

最后，让我们回到每个信道宽度的最大 RU 表，看看我们可以在一个 80 MHz 信道中使用四个双流 OFDMA STA 得到什么。表 27-6 上面说我们可以使用 242 tone RU，下面的表 27-81 说我们的四个 STA 中的每一个最多可以获得 287 Mbps 数据速率。还不错，但不如单个双流 80 MHz 带宽 STA 获得的 1201 Mbps。值得注意的是 4 x 287 = 1148。因此，将四个 STA 放入一个传输帧中会产生 4% 的数据速率损失。

OFDMA 测试

考虑到通常情况下 OFDMA 未启用，路由器制造商并未提供如何测试它的指导。设备制造商也对此守口如瓶，尽管 Broadcom 提供了一些建议，以展示 OFDMA 的最佳性能。而 Qualcomm 尚未与我讨论 OFDMA 测试的时间。

Intel 提供了一些帮助，提供了一些 AX200 适配器并回答了一些问题。然而，我从 linux-wireless 邮件列表 的开发者那里得到了更多信息。来自 Intel 德国的 Johannes Berg 在捕获 OFDMA HE-MU 数据包方面提供了关键信息。

我还需要感谢两家设备制造商对我的帮助。Arris（现在是 CommScope 的一部分）安排了 Broadcom 安装了一个特殊的固件加载，基本上将他们的 mAX Pro mesh 路由器变成了 Broadcom 参考 AP。这使我完全掌握了涉及 UL 和 DL OFDMA 的各种 AP 参数的控制。如果没有他们的帮助，我将无法使用支持双频 UL 和 DL OFDMA 的 AP。

NETGEAR 也非常乐意提供帮助，参与了多次 OFDMA 测试方法讨论，并回答了我提出的任何问题。

下图显示的 OFDMA 测试平台本质上与 Wi-Fi 6 RvR 测试使用的相同。一个通过电缆连接的单个 Intel AX200 STA 已被替换为一个内置了四部三星 S10e 智能手机的 octoScope Box18。四根 octoScope 高增益双频天线捕捉 RF 信号，而四通道 90 dB 范围可编程衰减器（quadAtten）用于衰减信号水平。

quadAtten 输入到四通道双向 RF 分频器/合并器，其第二端口连接到 octoScope Pal-24 和 Pal-5 合作设备，这些设备具有自己的衰减器。这提供了添加 2.4 GHz b/g/n 和 5 GHz a/n/ac STAs 到测试组合的选项。

OFDMA 测试设置

这是 Arris mAX Pro 放置在 octoScope Box38 中。用于 OFDMA 测试的四根天线如图所示。

Arris mAX Pro 在测试室内

这是放置在较小的 Box18 中的四部三星 S10e 手机的情况。手机间距均匀，而且确实靠近天线。实验发现，轻微的倾斜有助于最大化信号水平。这种设置为每个 STA 提供了大约 -50 dBM 的最大 RSSI 水平。

第二个房间中的四部三星 S10e

我的测试测量启用和禁用 OFDMA 时四部手机的总 UDP 吞吐量。测试由一个使用 octoScope 平台运行测试并报告结果的 Python 脚本运行。Android adb shell 命令用于控制三星 S10 的关联以及在每部手机上运行 Magic Iperf 应用 中的 iperf3 的启动/停止。

脚本使用不同的数据包大小运行 UDP 流量的速率 vs. 范围（RvR）测试多次。具体来说，RvR 测试每个步骤运行 30 秒的 UDP 流量，使用 6 dB 步骤，0-36 dB 衰减范围。 RvR 测试使用 128、166、512 和 1500 字节数据包大小重复。 然后整个序列再次重复一次，以检查可重复性。 接着相同的序列上行测试。所有设备在每次 RvR 运行之间重新关联。

该测试显示了在一些数据包大小和信号水平组合中的总吞吐量增益。它还显示了在其他信号水平和数据包大小组合中的显著总吞吐量损失。由于 octoScope 系统在向 iperf3 端点运行下行流量时阻止了正常的 UDP 结果报告，所以我只显示了上行结果。

图表显示了启用和禁用 OFDMA 时 Arris AP 上的总吞吐量增益，Y 轴显示了结果，结果按数据包大小和应用衰减进行分组。例如，1500 字节（标准）数据包大小和 18 dB 的应用衰减可以获得 33% 的最高增益。

显然，这些结果没有逻辑上的进展。主要的一致性是当应用 24 dB 的衰减时吞吐量增益变负（手机报告的 RSSI 在中 -70 dBm 范围内）。我没有显示 30 和 36 dB 的衰减结果，因为这些值导致至少一个 STA 断开连接或报告基本无法使用的吞吐量。

OFDMA 增益 – 上行 – 第 1 次运行

第二次测试运行显示了结果的高度变异。在产生增益的条件中有大致的相关性，但增益值大多不同。

OFDMA 增益 – 上行 – 第 2 次运行

请记住，这些数据是由一个实质上是 Broadcom 参考设计的 AP 生成的。虽然你可以购买 Arris mAX Pro，但不能用于此测试的固件。

总结

推动 Wi-Fi 6 的炒作机器一直像 5G 移动技术背后的机器一样无耻。两者都在推动实际上并没有兑现他们口口声声承诺的更高带宽的产品，至少不带有大量详细说明的附加条件...如果你能找到的话。

但炒作和公然误导之间存在差异。当路由器制造商发布不支持关键的 802.11ac 特性——MU-MIMO——的路由器时，他们提供了明确的免责声明，比如 "MU-MIMO 就绪"。他们甚至在产品规格中明确说明，这些产品基于草案 11ac IEEE 规格。

而对于 AX，产品限制和关键缺失的功能的明确披露似乎成了过去。正如我在本文的开头所说，制造商正在出售依然不支持工作的 OFDMA 的 Wi-Fi 6 消费者路由器，这仍然是 (仍然是) 草案 802.11ax 标准的关键功能的第二年。而制造商仍然没有明确披露这一事实。

OFDMA 在产品营销材料中被突出展示，但产品尚未支持此功能的事实并没有。如果你能找到免责声明，它通常埋在规格表的脚注中，措辞含糊不清，甚至没有直接与所否认的规格相联系。营销材料或规格表也没有明确说明支持哪些 Wi-Fi 6 功能。

整个情况令人不悦，标志着 Wi-Fi 营销的新低。因此，路由器制造商，是时候公开并包含产品实际支持的 AX 功能的信息了。

是的，我知道这可能会成为一个相当长的列表，而且可能会随着时间的推移而改变。那么为什么不从那些在营销材料中明确宣传的关键功能开始，即 OFDMA DL 和 UL、DL MU-MIMO 和160 MHz 频道呢？这些功能最有可能影响实际消费者，因此它们的支持（或不支持）应该被明确说明。在支持这些功能时更新您的在线规格表，并通过固件更新说明或通过您一直在推动用户安装的应用程序提醒用户有关更改。

话虽如此，我仍在继续进行 Wi-Fi 6和其他测试方法的工作，目标是看看 Wi-Fi 6是否真的能够减少延迟，就像它所声称的那样。但如果我有一些真正完全支持（尚处于草案状态的）802.11ax 标准的实际产品来测试，那就太好了。

OFDMA 究竟是否有效？第一部分

介绍

在一月份的文章《你的 Wi-Fi 6 路由器缺少了什么？OFDMA》中，我曾经说 OFDMA 开始看起来很像 MU-MIMO。从那以后，我一直在继续开发 OFDMA 测试方法，尝试不同的方法，正如您很快会看到的。

底线是，我仍然无法一致找到所承诺的改善空间效率、使用多个设备的更高总带宽以及较低延迟的证据。

测试平台 V2

在先前的文章中，测试平台的 STAs 由 octoScope Box18 和四台三星 S10e 智能手机组成。四台 octoScope 高增益双频天线捕获 RF 信号，而四通道 90 dB 范围可编程衰减器 (quadAtten) 降低信号水平。

quadAtten 连接到四通道的双向 RF 分频器/组合器，其第二个端口连接到 octoScope Pal-24 和 Pal-5 合作设备，它们具有自己的衰减器。这提供了将 2.4 GHz b/g/n 和 5 GHz a/n/ac STAs 添加到测试中的选项。分频器连接到一个包含受测试设备 (DUT) 的 38 英寸 octoScope 盒中，其中有四个 octoScope 高增益双频天线。

OFDMA 测试平台 – 第一个尝试

这种测试方法测量了启用 OFDMA 和禁用 OFDMA 时的四部手机的总 UDP 吞吐量。最终，这种方法，即使用 Broadcom 建议的小数据包大小的 UDP 流量，并没有产生显著或可重复的吞吐量增益。

这一次，我决定专注于测量延迟，以尝试验证 OFDMA 是否确实显著降低了延迟的说法。新的测试平台使用了四个 octoScope STApals。这些是迷你的 ASUS pico-ITX 格式计算机，配备了 Intel AX200 Wi-Fi 6 网卡。STApal 有两个版本，一个基于 Ubuntu Linux，另一个运行 Windows 10 Pro。选择了 Windows STApal 版本，因为在测试时，其 AX200 驱动程序具有更好的上行和下行吞吐性能，而不是 Linux 驱动程序（octoScope 正在努力纠正这一点）。

OFDMA 测试平台 – 第二版本

测试平台还配备了一个 octoScope Pal6。它可以用来添加流量负载，但我使用它来监视信道拥塞。稍后再详细介绍。

测试是通过一个使用 octoScope octoBox 服务器平台运行测试和报告结果的 Python 脚本来完成的。octoScope 的 multiperf 流量生成器（以 iperf3 为核心）提供流量生成。

基本的测试方法受到了“Make Wi-Fi Fast 项目”的 RRUL（负载下实时响应）bufferbloat 测试工具的启发。具体来说，我使用了 Flent 的 rtt_fair_var 测试，将其移植到 octoScope 测试平台上。然而，所有初步探索都是使用 Flent 本地执行的，得益于 Flent 的创始人 Toke Høiland-Jørgensen 的大力帮助。 （感谢，Toke！）

作为对 Toke 的额外感谢，这是对他的博士论文 "Bufferbloat and BeyondRemoving Performance Barriers in Real-World Networks" 的一个不知羞耻的推销链接。它更详细地介绍了 Flent 和 Toke 在“终结 wifi 异常”方面的工作。

Flent 使用 netperf，而不是 iperf/iperf3 作为其主要的流量生成/基准工具。Netperf 在 Linux 系统上（需要编译）相对容易安装，但在 Windows 上安装较为困难。长话短说，我最终创建了 Windows 版本的 netperf 和 netserver 二进制文件。 （下载包含这两个文件的 zip 文件）。

rtt_fair_var 测试是 Realtime Response Under Load (RRUL) 测试的一个变种，它是 Flent 测试套件的核心。对于每个测试 STA，测试同时运行一个 ping，间隔 200 毫秒，以测量往返时延（延迟），并使用 netperf 发送无限带宽的 TCP/IP 流量，以通过流量淹没连接。

以下是使用 Flent 进行早期测试的一些典型结果。DUT 是一台 ASUS GT-AX11000，当时只支持 5 GHz 下行（download）流量的 OFDMA。第一个图是 OFDMA 关闭时的结果…

Flent RTT Fair 测试 – CDF 延迟图 – BE 优先级 – OFDMA 关闭

而第二个图则是开启 OFDMA 时的结果。CDF（累积分布函数）图显示一个量（在这种情况下是 ping 或 RTT）将小于或等于一个值的概率。80%（图中的 0.8）通常用作基准，因此我们可以看到，OFDMA 关闭时，所有三个流量对的平均 ping 时间在 80% 的时间内将低于或等于 30 毫秒，而开启 OFDMA 时，这将增加到 ~ 120 毫秒或更低。不是我们要找的结果！

Flent RTT Fair 测试 – CDF 延迟图 – BE 优先级 – OFDMA 开启

是否支持 OFDMA？

尽管消费级路由器制造商正在逐渐将 OFDMA 引入其产品中，但大多数 Wi-Fi 6 产品仍然没有启用 OFDMA。即使支持 OFDMA 的产品中，只有少数支持 5 GHz 或双频带的 DL 和 UL OFDMA。

我经常向 ASUS 和 NETGEAR 询问 OFDMA 支持的最新情况。我已经放弃向 TP-Link 了。每次我询问时，回复都是他们的 Wi-Fi 6 产品仍然不支持 OFDMA。D-Link 只出售 DIR-X1560，它只支持 5 GHz 上行 + 下行 OFDMA（2.4 GHz 使用 11n 无线电）。Linksys 只有其价格过高的 MX5/MX10 Velop AX Mesh 系统；我没有向他们询问 OFDMA 支持情况。

上次与 ASUS 的检查大约一个月前显示，所有其 AX 路由器都支持 5 GHz 下行，同时支持 5 GHz 上行和 2.4 GHz 下行/上行，标记为“即将开放”。但 SNBForums 上 Merlin 的提示让我在当地的 Best Buy 提前取货，购买了 RT-AX58U（又名 RT-AX3000）。对其 GUI 的快速检查显示，它确实在两个频段上提供了 DL、DL/UL 和 DL/UL+MU-MIMO OFDMA 设置。

NETGEAR 的列表显示，其入门级的双流 RAX15/20 和中档 RAX45/50 路由器支持完整的 OFDMA（双频段，DL+UL）。在 NETGEAR 的早期 AX 路由器中，RAX80 仍然不支持 OFDMA，而其唯一基于高通芯片的路由器 RAX120 支持双频段的 DL。对于那些喜欢购买昂贵的三频段路由器的人，至少 RAX200 支持完整的 OFDMA。其 Orbi 和 Nighthawk Wi-Fi 6 网络系统都支持完整的 OFDMA。我购买了 RAX15 和 RAX45（Costco 专供款）进行测试，并要求 NETGEAR 发送 RAX200。但由于 Covid-19，他们无法发送，而我目前没有足够多的现金来支付 Amazon 目前的 $488 售价。

最佳情况

当我在 octoScope 测试平台上运行类似于 Flent rtt_fair_var 测试的等效测试时，一位 octoScope 同事分享了一些他使用类似 TCP/IP 流量加 ping 测试应用于 octoScope 的 Pal6 合作设备（配置为 AX AP）的令人鼓舞的结果。因此，我决定尝试使用 Pal6 配置为四流 AX AP 进行实验。以下所有的图形都是通过将 CSV 测试结果文件导入到 octoScope 的 Expert Analysis 工具生成的。

以下四个 WinSTAPals 生成以下图形的 TCP/IP 流量设置如下：

• 50 Mbps 比特率（iperf3 -b）
• 256 字节缓冲区长度（iperf3 -l）
• DSCP = 192（iperf3 –dscp）

DSCP 参数设置了流量的优先级级别。如果您搜索有关 DSCP 的信息，您将发现很多不同的参考文献，提供了很多不同的 DSCP 设置值。对于 octoScope 系统，192 值相当于 CS6 无线 QoS 数据帧的语音优先级。这经过数据包检查进行验证。

请注意，当 Pal6 上的 OFDMA 设置为关闭时，MU-MIMO（MU 波束成形设置）仍然启用。Pal6 有单独的下行和上行 OFDMA 启用；在 OFDMA 开启条件下，两者都已启用。

第一个图比较了所有四个流量对的 OFDMA 开/关的平均延迟。显然有显著的改进；从约 48 ms 到约 6 ms。

Pal6 AP – 平均延迟 CDF 比较 – 下行

上行的延迟比 OFDMA 关闭时更低，但与其开启时的下行延迟差不多。

Pal6 AP – 平均延迟 CDF 比较 – 上行

OFDMA 还宣称能提高多个设备的 总吞吐量。下行吞吐量图似乎也支持这一说法，但不是在图的开始。这种需要时间来稳定的行为在多次运行中都有看到。

Pal6 AP – 平均下行吞吐量比较

上行吞吐量几乎没有从 OFDMA 中获得收益。

**Pal6 AP – 平均上行吞吐量比较**

802.11ax 的基本原则是高效率；这已经体现在了标准的名称中，也是其主要任务。如果 AX 能够实现其主要目标，那么无线信道的利用将更加高效。高通芯片组报告信道拥塞情况，因为 Pal6 基于高通的 AX “鹰眼 2.0” 芯片组，所以我们有下面的图。启用 OFDMA 后，拥塞减少了 50% 以上！

Pal6 AP – 信道拥塞比较 – 下行

上行也显示启用 OFDMA 后拥塞较低，但与下行拥塞相比，增益没有那么明显。

Pal6 AP – 信道拥塞比较 – 上行

对我来说，这最后两个图是最重要的。因为即使延迟没有减小，总吞吐量没有增加，减少信道拥塞意味着设备竞争较少，这应该会让所有使用同一信道的人获得更好的 Wi-Fi 体验。

所以看起来我们终于有了一个基准，可以显示 OFDMA 会有显著的好处（在大多数情况下）！

无限比特率

但由于 rtt_fair Flent 测试使用了无限比特率，因此我试着看看会发生什么。所有其他流量参数保持不变。

对于下行流量来说，OFDMA 开/关的平均延迟并不令人鼓舞。尽管与每个 STA 的 50 Mbps 比特率相比，启用 OFDMA 的变化方向是错误的。

Pal6 AP – 平均延迟 CDF 比较 – 无限吞吐量 – 下行

上行在两种情况下的延迟更高，但至少在启用 OFDMA 时有所改善。

Pal6 AP – 平均延迟 CDF 比较 – 无限吞吐量 – 上行

当启用 OFDMA 时，下行总吞吐量也朝着错误的方向发展。

Pal6 AP – 平均下行吞吐量比较 – 无限吞吐量 – 下行

与之前的有限比特率一样，上行吞吐量显示几乎没有从 OFDMA 中获得的收益。但变化更大。

Pal6 AP – 平均上行吞吐量比较 - 无限吞吐量 - 上行

最后，启用 OFDMA 时，下行信道拥塞再次朝着错误的方向发展，增加了一倍多。

Pal6 AP – 信道拥塞比较 - 无限吞吐量 - 下行

至少，上行信道拥塞并没有像启用下行 OFDMA 一样大幅增加。

Pal6 AP – 信道拥塞比较 - 无限吞吐量 - 上行

我还运行了将每个 STA 的比特率设置为 5 Mbps 和 100 Mbps 的测试，并看到启用 OFDMA 后一些基准改善，而其他基准则变差。因此，似乎这个基准并不像我所希望的那么稳健。

改变优先级

在 Flent 的基准测试中，有一些使用不同的流量优先级的测试，这是个好主意。从理论上讲，标记为语音和视频的流量应该比较低优先级的“尽力而为”流量具有更低的延迟。但 OFDMA 是否会对流量优先级产生帮助或伤害呢？

为了找出答案，我为每个四个流量对分配了不同的流量优先级。一个 STA 使用最佳尽力而为的 CS0（默认值），一个 STA 使用“出色尽力而为” CS3，第三个 STA 使用 CS5 视频，第四个 STA 使用 CS6 语音。

Flent RRUL 测试通常不限制吞吐量。之前，我已经通过设置无限比特率来尝试了这一点。但设置缓冲区长度也会对吞吐量进行限制。因此，下一个测试结果中，比特率（iperf3 -b）是无限的，缓冲区长度（iperf3 -l）未设置。

下面的图表中的流量优先级关键如下：

• Ping 对 1: CS0（最佳尽力而为）
• Ping 对 2: CS3（出色尽力而为）
• Ping 对 3: CS5（视频）
• Ping 对 4: CS6（语音）

随着信道负载充分（拥塞度约为 90-95%），延迟增加。但关闭 OFDMA 的下行图显示不同流量优先级的延迟存在差异。奇怪的是，最低优先级的最佳尽力而为 STA 具有最低的延迟，而最高优先级的语音 STA 具有最高的延迟。

Pal6 AP – 每个 STA 的延迟 - 下行 - 关闭 OFDMA

启用 OFDMA 不会显著降低延迟。相反，所有 STA 的延迟都朝着错误的方向移动，视频 STA（Ping 对 3）竟然超越语音，成为延迟最高的。

Pal6 AP – 每个 STA 的延迟 - 下行 - 启用 OFDMA

关闭 OFDMA 的上行结果更加有趣。较低优先级的 CS0 和 CS3 STA 明显具有较低的延迟，以及较低的延迟差异（曲线越陡，值差异越小），而“较高”优先级的 CS5 和 CS6 STA 则具有较高的延迟。

Pal6 AP – 每个 STA 的延迟 - 上行 - 关闭 OFDMA

启用 OFDMA 稍微降低了较低优先级 STA 的延迟，但增加了语音和视频的延迟。

Pal6 AP – 每个 STA 的延迟 - 上行 - 启用 OFDMA

供参考，以下是关闭 OFDMA 的下行图，比特率为 50 Mbps，缓冲区长度为 256 字节。在这种情况下，信道拥塞平均约为 25%。即使水平尺度扩大，也很难看出延迟有明显的差异。

Pal6 AP – 每个 STA 的延迟 - 下行 - 关闭 OFDMA - 50 Mbps 比特率 - 256 字节缓冲区长度

总结思考

我认为你可以看出为什么我正在将 Wi-Fi 行业最新和最大的炒作与 MU-MIMO 放在一起，MU-MIMO 也是802.11ax的一部分，并对这些结果产生了一些影响，OFDMA 在理论上非常出色，但在实际实施中非常困难。

我不能说我感到惊讶；空时管理是一个非常困难的任务。而 OFDMA 只会使它变得更加困难。对于每个要发送到等待的 STA 的数据包，AP 必须在以下选择之间进行选择：

• 将其直接放入传输队列
• 为该 STA 的其他数据包保留它以进行聚合
• 保留它，无论是否进行聚合，以通过 MU-MIMO 与其他 STA 的数据一起发送
• 保留它，无论是否进行聚合，以通过 OFDMA 与其他 STA 的数据一起发送

这些决策必须考虑客户端类型混合（a/b/g/n/ac/ax）、信号强度和物理位置以及流量类型混合（语音/视频/浏览/文件传输/IoT）和负载的影响。与 MU-MIMO 一样，OFDMA 可能需要多年的时间才能达到实际增加价值的程度。

与此同时，我仍在努力弄清楚如何进行 OFDMA 测试，并将在第二部分中呈现结果。我已经在一组我知道已启用 OFDMA 的 AX 路由器上运行了这里描述的基准测试的某个版本。到目前为止，根据所使用的基准测试设置，我已经看到启用 OFDMA 后的空间时间拥塞和延迟变得更糟。如果有人有任何聪明的想法，请分享！

OFDMA 究竟是否有效？第2部分

介绍

在第1部分中，我详细介绍了如何开发我的 OFDMA 基准测试。在第二部分中，我将展示经过测试的两款 Wi-Fi 5（802.11ac）和六款 Wi-Fi 6（802.11ax）路由器的结果。这些路由器都经过了完整测试过程。

我使用了第1部分中描述的测试的最后一个变体。总结如下：

• iperf3 TCP/IP 流量同时运行到四个 STA（Intel AX200，Win 10，21.80.2.1驱动程序）
• 比特率（-b）：50Mbps
• 长度（-l）：256字节
• DSCP值（-dscp），每个STA一个：0（CS0），96（CS3），160（CS5），192（CS6）
• 从 AP 到每个 STA 的每一对同时运行的 200ms 间隔 ping。Ping 始终是从 DUT 到 STA，用于上行和下行流量。
• 使用与 DUT 关联的 octoScope Pal6（Qualcomm AX基础）来测量拥塞，运行 1bps 的流量以记录统计信息。

表1显示了经过测试的路由器，以及其主要属性。

表1：已测试路由器

由于有很多路由器，包括所有产品会变得难以阅读。因此，我将为 ASUS 和 NETGEAR 路由器分别显示不同的图表。这两套图表将包括两个 Wi-Fi 5 路由器和 octoScope 的 Pal6 ，配置为四流 AX AP 供参考。

NETGEAR R7800 是一款四流 Wi-Fi 5（802.11ac）路由器，是我“常备”的 AC 参考路由器。每当我有一个表现奇怪的产品时，我都会把R7800 放回测试室，以确保是产品，而不是测试平台出现了问题。

基于 OpenWRT 的 Evenroute IQrouter V3 被包含在内，因为它在其 Mediatek 芯片组的无线驱动程序中集成了 MakeWiFiFast 小组的codel 和空时公平性工作。IQrouter 的功能集主要侧重于优化有线路由性能，特别是减少缓冲区过载对路由器的 ISP 连接的影响。但由于它还具有一些减少 Wi-F i延迟的功能，因此将其包含在内，以查看其与 R7800 和 AX 产品的性能差异。

（不是那么）有趣的故事；实际上，我写了两篇文章。第一版发布大约15分钟后，我将其删除，因为数据有误。文章发布后不久，我回到测试平台，开始重新配置它，发现其中一个 STApal 的一个通道没有连接。是的，就这样悬在那里。在一番口头的自我抨击和实验室墙壁上多次打击之后，我开始重新采集数据。

但在这个过程中，我认为我可能会改进测试配置，以更好地支持 MU-MIMO。经过多年未增加 Wi-Fi 性能价值的历史，我被告知 MU-MIMO 实际上现在有效，至少是 802.11a c下行形式的 MU-MIMO。802.11ax 标准增加了上行形式的 MU-MIMO，但在首批 AX 芯片组中没有支持它。

MU-MIMO 使用波束成形，需要空间多样性，即设备必须物理分离。测试平台并不支持这一点，因为所有四个 STApals 都使用相同的两个天线。

下面的图表显示了测试平台的新配置。每对 STApals 都有自己的衰减器，连接到它们自己的一对天线，位于38英寸的八面体盒子的角落。1:4 RF 分配器/合并器的未使用端口都有50欧姆终端。理想情况下，每个 STApal 都应该有自己的一对天线，坐在盒子的角落。但即使这种非理想的配置也揭示了在测试运行中启用和禁用 MU-MIMO 时的性能差异。

OFDMA测试平台 - 更新后

现在，让我们看一下结果。

延迟

ASUS

我们将首先总结在表2中关闭 OFDMA 和开启 OFDMA 时的80%概率下行延迟。

表2：ASUS路由器 OFDMA 延迟摘要 - 下行

第一个图展示了 ASUS 路由器和三个“参考”产品的 OFDMA 关闭的下行延迟，使用80%概率基准。尽管所有 ASUS AX 产品都相对密集地聚集在一起，但参考的 octoScope Pal6 不是。请注意，两个 AC 参考产品，IQrouter v3 和 NETGEAR R7800，表现类似。

ASUS下行延迟 CDF – OFDMA关闭 – 下行

我至少检查了6次 Pal6 的结果。以下是一些结果，其中上面用 黑色粗体 标示的数值。

Pal6下行延迟 CDF – OFDMA关闭 – 下行 – 重测

启用 OFDMA 的下行延迟 图确认了上面表格中的结果。Pal6 的延迟改善最多，减少了71%。RT-AX58U 是唯一一个表现更差的路由器，延迟增加了35%。尽管如此，所有的 ASUS 路由器的延迟仍然好于 AC 参考路由器。

ASUS下行延迟 CDF – OFDMA开启 – 下行

转向 上行延迟，80%概率的延迟在表3中总结了 OFDMA 关闭和开启的情况。再次，Pal6 的延迟得到了最大的改善，减少了57%。而且，RT-AC58U 再次是三款ASUS路由器中唯一延迟恶化的路由器。

表3：ASUS路由器OFDMA延迟摘要 – 上行

关闭 OFDMA 的上行延迟 图清楚地显示了所有的 ASUS 路由器与“参考”产品之间的差异。

ASUS上行延迟 CDF – OFDMA关闭 – 上行

启用 OFDMA 的上行延迟 图显示了Pal6延迟的显著变化。再次，AX产品通常比AC产品具有更低的延迟。

ASUS上行延迟 CDF – OFDMA开启 – 上行

NETGEAR

表4总结了三款 AX NETGEAR 路由器在关闭 OFDMA 和开启 OFDMA 时的80%概率下行延迟。与三款 ASUS 路由器一样，所有三款NETGEAR 路由器的 OFDMA 关闭延迟都低于两款 AC 参考产品和 Pal6 参考产品。基于 Broadcom 的 RAX15 和 RAX45 的延迟约为Qualcomm-based 的 RAX120 的一半，这是本次测试中唯一一款基于 Qualcomm 的路由器。

表4：NETGEAR路由器OFDMA延迟摘要 - 下行

这里是 禁用 OFDMA 的下行延迟 图表...

NETGEAR 延迟 CDF – OFDMA 关闭 – 下行

还有下面的 启用 OFDMA 的下行延迟，没有太多其他要说的。

NETGEAR 延迟 CDF – OFDMA 开启 – 下行

转向 上行延迟，80% 概率延迟在表5中分别总结了 OFDMA 关闭和开启的情况。对于 RAX120 来说，与下行相比，延迟改善要好得多。但启用 OFDMA 似乎严重地影响了 RAX15。为了核实，我重复了测试，结果类似。

表5：NETGEAR 路由器 OFDMA 延迟摘要 – 上行

禁用 OFDMA 的上行延迟 图表显示了相对于下行图表而言的明显向右移动（更高延迟），正如我们在 ASUS 路由器上所看到的。请注意，RAX120 的延迟高于 R7800。

NETGEAR 延迟 CDF – OFDMA 关闭 – 上行

启用 OFDMA 的上行延迟 图表显示，RAX120 现在比 R7800 更好，与 IQrouter v3 大致相当。RAX15，则像他们说的，破表了，但不是一种好事。

NETGEAR 延迟 CDF – OFDMA 开启 – 上行

结论：我的关于延迟的看法是，OFDMA似乎能够降低一些延迟。但我怀疑这种效果在实际世界中是不会被注意到的。这不是像打开 OFDMA 就能将延迟从数百毫秒减少到1毫秒那样显著的效果。

效率

AX 的首要指令是提高空间效率，即使用更少的空间来传输给定数量的数据包。幸运的是，octoScope的 Pals 测量了空间拥塞。因此，通过查看 OFDMA 开启和关闭时的拥塞差异，我们可以看到 AX 是否遵循了其指令。我将使用由与 DUT 相关的 Pal6 测量的空间拥塞的条形图来展示OFDMA的作用。

下行拥塞 图表显示了三台ASUS路由器，每对中的第一个条形图表示关闭 OFDMA 时的平均拥塞，第二个条形图表示开启时的拥塞。尽管拥塞相对较低，大约在25%左右，但你会注意到每个产品在启用 OFDMA 时都略微增加了拥塞。然而，就像我们在延迟中看到的那样，你在现实世界中不会注意到这一点。

ASUS 空间拥塞 – OFDMA 效应 – 下行

我没有在上面的图表中包含 Pal6 和两台AC参考产品，因为Pal6会压缩比例，使细微的空间拥塞变化难以看到。因此，这些产品分开绘制。看起来，Pal6的高延迟和高拥塞是相关的。

参考产品空间拥塞 – OFDMA 效应 – 下行

以下是 ASUS 三兄弟的上行拥塞 图表。空间使用量是下行的两倍多。这一次，启用 OFDMA 稍微降低了拥塞。但你不会注意到它，而且这很可能只是测量的变异。

ASUS 空间拥塞 – OFDMA 效应 – 上行

以下是参考产品的上行拥塞。IQrouter v3 和 R7800 在这个方向上的拥塞都较低。但看看Pal6！它几乎减少了20%的拥塞，这是我在所有这些测试中看到的最显著的变化。

参考产品空间拥塞 – OFDMA 效应 – 下行

现在轮到 NETGEAR 了。以下是 下行...

NETGEAR 空间拥塞 – OFDMA 效应 – 下行

...和下面是上行。最终，有一款产品脱颖而出，那就是双流的 RAX15。它的拥塞要低于所有其他经过测试的产品，而且启用 OFDMA 时拥塞明显降低。实际上，所有三款NETGEAR路由器在启用 OFDMA 时都显示出较低的拥塞。但对于RAX45来说，降低幅度相当小。

正如我们在 ASUS 路由器中所看到的，三台 NETGEAR 路由器的上行拥塞是下行的两倍多。RAX15 在启用 OFDMA 时的拥塞增加足够大，是真实的。但 RAX120 和 RAX45 拥塞的变化可能在测量精度内。

NETGEAR 空间拥塞 – OFDMA 效应 – 上行

结论：虽然有一些证据表明 OFDMA 会影响空间效率，但当看到效果时，它非常轻微。

吞吐量

启用 OFDMA 后的总吞吐量改进情况并不比延迟或拥塞要好。OFDMA 在这里的期望效果是更高的总吞吐量。但在这些测试中，如果有任何改进的话，都非常轻微；远远在我处理任何 Wi-Fi 测量时使用的 +/- 5% 的经验法则范围之内。我将使用平均吞吐量的条形图，因为时间图并没有太多帮助。

我将使用与空间拥塞相同的绘图方法，首先是 OFDMA 关闭，然后是开启，对每个产品进行绘制。以下是 ASUS 下行。这里没有太多可看的。

ASUS 平均总吞吐量 – OFDMA 效应 – 下行

以及参考产品的下行平均吞吐量。Pal6 的 OFDMA 关闭时吞吐量较低，与我们之前看到的更高延迟一致。

参考产品平均总吞吐量 – OFDMA 效应 – 下行

以下是 上行。除了平均吞吐量较低约 20 Mbps 之外，这里也没有太多可看的。

平均总吞吐量 – OFDMA 效应 – 上行

这是参考产品的上行。对于 Pal6 来说，在 OFDMA 开启/关闭时没有太大的差异。

参考产品平均总吞吐量 – OFDMA 效应 – 上行

转向 NETGEAR。下行...

NETGEAR 平均总吞吐量 – OFDMA 效应 – 下行

...和 上行。唯一显著的变化是 RAX15，与期望的方向相反。这似乎与之前观察到的拥塞的巨大变化相一致。

NETGEAR 平均总吞吐量 – OFDMA 效应 – 上行

结论：OFDMA 对于总吞吐量没有任何改善。

关于吞吐量的最后一个观察是，请注意，这个基准测试使用了四个50 Mbps的吞吐流，但没有一个产品达到了200 Mbps的总吞吐量。我进行的实验显示这部分原因是由于流量优先级的混合，部分原因是由于缓冲长度的限制。

总结

消费级路由器制造商在其 Wi-Fi 6 产品中启用 OFDMA 已经等待了很长时间。在此期间，我尝试了各种 OFDMA 测试方法，有些是由 Broadcom 建议的，有些是由路由器制造商建议的。我目前的结论是，对于普通消费者来说，OFDMA 没有明显的好处。

可能会有更多的设备和不同的流量组合显示出延迟、吞吐量和/或空时拥塞的改进。但使用情况非常具体，改进不足以使 OFDMA 成为购买Wi-Fi 6 路由器的理由。

目前，我将搁置我的 OFDMA 测试工作，重新设计一个新的 Wi-Fi 测试套件，以便我可以继续产品测试。不幸的是，OFDMA 只是又一个从移动/蜂窝世界借用来的技术，在 Wi-Fi 世界中并没有取得好的效果，这里设备而不是网络才是主导。