关于无线(802.11a/b/g/n)网络中动态速率选择如何工作,我有两个相关问题:
这种速率缩放发生在什么时间尺度上?我认为它实际上发生的频率比 Windows 无线实用程序等向用户报告的变化频率要高得多,大约以毫秒为单位。
如果我说得没错,速率选择实际上是以毫秒为单位进行的,那么无线实用程序(例如 Windows 内置的实用程序)如何决定报告什么速度?它们通常会报告过去几秒内的最小值、最大值、中值等吗?
答案1
任何时候,数据包必须在 802.11 层重新传输(因为在数据包传输结束时的 Ack 窗口内未收到 802.11 层 Ack),传输设备可能会选择以较低(更稳健)的速率发送重新传输。因此,速率可能会从一个数据包立即变为下一个数据包,所以是的,如果不是更快的话,时间尺度为毫秒。还请注意,速率不一定是对称的。因此,客户端可能使用一种速率向 AP 传输,但 AP 可能使用不同的速率向该特定客户端传输。如果您的 GUI 仅报告连接的一种“速度”,它是报告此设备传输的速率,还是其他设备向此设备传输的速率?
对于向用户报告速率的软件是否应该报告发送或接收的最后一个数据包的瞬时速率,或者是否应该应用某种平均或滞后,没有标准。我在这里看到了相当多的差异,这取决于工具/操作系统/驱动程序的组合。即使它报告了调用“GetRate()”(可以这么说)API 时最后一个传输的数据包的速率,用户级工具调用该 API 的频率是多少?每 10 秒一次?每秒一次?每秒多次?
我怀疑是否有人有足够的数据来说明“通常”会做什么。如果您仔细研究您最喜欢的开源工具/操作系统/驱动程序的代码,那么您就可以说出这种组合的行为方式。祝您好运,找出闭源工具/操作系统/驱动程序在这方面的行为方式。
我确实见过报告最新接收速率的工具/操作系统/驱动程序组合,因为当连接基本处于空闲状态时,它通常会显示一个较低的数字(与多播速率相对应)。因此,当没有发送或接收真正的单播流量时,软件将看到所有以较低多播速率进行的多播背景聊天,并将其报告为连接速度。在这种情况下,如果您真的想了解连接能够达到的速度,您需要在连接上来回发送大量单播流量,这样您就会看到报告的单播数据速率通常要高得多。
答案2
我怀疑它是否发生在毫秒级。很有可能,如果有足够多的丢包,它会自动降级到连接,直到丢包的百分比可以容忍。
无论当前是什么情况,Windows 都会报告。
进行缩放的原因是,如果路由器尝试保持相同的速度,则会出现太多数据丢失。
影响数据丢失的因素有:
- 距离
- 无线电干扰
- 阻碍信号传输的物理物体
- 发射机功率
由于这些因素不会快速变化,并且路由器可扩展的速度非常有限(无线 b 为 4,无线 g 为 8),因此没有理由每毫秒进行检查,或期望扩展率快速变化。