atheros 性能问题分析- TCP长连接下载瞬时速率会突然下降到一个极低的值

问题描述：

在某种干扰条件下，atheros  9344的芯片会复位，导致瞬时丢包、业务中断。

问题现象是：一个TCP长连接下载（超200MB文件下载），

下载过程中，速率慢慢上升达到最高值（例如2MB/s)，几秒种后，速率会突然下降到一个极低的值（如30KB/s)，甚至为0。

驱动打印出"mac hang is detected!"错误报告。

原因初步分析：

mac hang is detected意味着硬件资源耗竭，需要将芯片复位。物理层瞬时丢弃了发送队列的所有报文

（约8个队列，每个队列最多存4个聚合帧，最多可达32个报文），

TCP/IP协议栈会重传丢失的报文并自动将TCP滑动窗口减小，导致吞吐率突然下降，所以速率显示为几十KB/s。

严重的话，因丢包过多，TCP连接会被复位，上层应用支持自动重连时，会在连接过程中显示当前速率为0。

定位线索有：

1、这属于软件的BUG，非硬件问题。尝试过在相同的硬件板子上更换FLASH芯片，即软件更换后问题不存在。

2、出问题的AP是一款WMM-Enabled的AP。这应该属于WMM Flow Control and Buffer Management特性中的问题。缓冲队列调度存在BUG。而且可能是因为

存在高优先级的BEACON帧(每秒10个）要发送，导致低优先级的数据队列（BE）饿死。

尝试将wmm关闭 #iwpriv wlan0 wmm 0 ，mac hang不再打印，速率突然下降现象消失。应该没再出现批量丢包。

3、理论上，因干扰存在，报文是有可能没机会发出，无线丢包是一个常态。但随机个别丢包只会出现速率上下波动的现象，而不会出现该速率直线下降直到0的现象。

因此，这现象应该跟硬件复位导致集中批量丢包有关。同样是丢包现象，其实质不一样。

4、现象发生时，会经常走到ath_tx_draintxq 这个分支。意味着发送停止，丢包发生。关掉WMM后，也偶而会走到这个分支，但非常少约1-2个。

5、MAC HANG意味着MAC层被吊死。它是如何检测的呢？

实际检测函数是hal/ar9300/ar9300_misc.c的HAL_BOOL ar9300DetectMacHang(struct ath_hal *ah)

是靠读硬件寄存器得到的结果。