Steam Deck OLED WLAN下载速率过低问题的排查和解决

最近在给某大型游戏公司调试Wi-Fi,具体的硬件平台信息如下所示:

Processor

6 nm AMD APU

CPU: Zen 2 4c/8t, 2.4-3.5GHz (up to 448 GFlops FP32)

GPU: 8 RDNA 2 CUs, 1.6GHz (1.6 TFlops FP32)

Wi-Fi

Qualcomm QCA2066

Tri-band Wi-Fi 6E radio, 2.4GHz, 5GHz, and 6GHz 2 x 2 MIMO

IEEE802.11a/b/g/n/ac/ax

Kernel Version

6.1.x

Wi-Fi Driver

ATH11K

到这里,大家应该能猜到是那个项目,hahaha...。没错,就是如你所想的那样,Valve的最新一代Steam Deck OLED:Steam Deck™ 


言归正传,回归到我们的问题点:客户在进行5G/6G 160Mhz带宽下的TPUT测试,按照理论计算2.4G(具体为啥是2.4G,可以查看:WLAN物理层速率计算方式_wlan速率计算公式-CSDN博客) x (0.7 ~ 0.8) = (1.68G ~ 1.92G),但是我们实际测试结果DL的速率只能达到1.2+G左右(具体如下图所示),这明显无法满足标准。

 基于此,我们着手开始排查问题的原因。在看到问题那一刻,我们按照正常的排查思路(所谓的三板斧),首先怀疑的第一点是:系统的调度资源是否满足?

所使用的工具是mpstate(关于mpstate工具的使用方法,各个平台都有很多介绍,可以自行搜索学习,这里不做过多的描述),果然不出所料,进行Rx TPUT测试时,系统的软中断100%,系统idle为0%,具体如下图所示:

此时我们暂时不去追究更多的细节问题,首先从上图可以看出:表象原因是系统资源不够了到此,我们是不是无处着手,先不着急,需要用到我们的另一大法:对比排除法

因为我们在kickoff此项目之前,已经在Intel X86 ubuntu18.04平台上进行过我们Wi-Fi平台的性能摸底,所以肯定Wi-Fi芯片的能力是足够的,所以我们首先想到的是:是不是内核配置有差异?

最后确定差异点是:AMD平台上的IOMMU被关闭了(这其中如何发现IOMMU的这里不做详细描述,真的是一语难尽啊,做了大量的数据测试,真是一把辛酸泪)。

排查到这里,可终于让人轻松了一把,我们以为使能IOMMU就能解决此问题,开开心心,写了一长篇的邮件(从如何发现问题,如何排查,如何解决此问题)给Valve客户(以此来邀功),可是打脸的总是那么及时,很快心就凉了一截。Valve客户给我们的反馈是不能打开IOMMU,因为他们要使用GPU,IOMMU是降低GPU的性能。所以解决此问题还得另辟蹊径。

紧急召开了AMD/Qualcomm/Valve/我司的一个四方会议(巴拉巴拉的一堆英语,有时候听个半懂),最后定位到是DMA的mapping因为关闭了IOMMU,所以在进行数据转发时耗费了大量的软中断。

这里关于DMA mapping的相关知识,请参考此链接:Dynamic DMA mapping Guide — The Linux Kernel documentation

我们在进行Rx TPUT的时候,使用的DMA是Streaming DMA mappings方式,此方式的DMA mapping是通过IOMMU进行的,因为我们把IOMMU关闭掉了,所以才会使用软中端进行mapping。所以,这里引出一个思考点:为什么会进行地址的mapping呢?我们有没有办法让它不要进行软中断的mapping呢?

要不说Qualcomm的东西虽然贵但是好用呢,这不就找到方法了么:

由于此前我们将Wi-Fi PCIe的DMA MASK设置到了32位,所以能寻址的范围为0~4G,但是因为Rx TPUT时,socket buffer的随机性,很大概率会分配大于4G以上的内存地址,此时就需要进行地址的转换,那如果IOMMU是使能的话,这个活就不需要CPU的参与了,但是好巧不巧,IOMMU是被关闭的,所以这个事情就只能交给CPU处理,这不就让CPU很吃力嘛,但是没办法,必须干啊,不干就没办法进行Rx了。

这时候我们想到,如果不让进行地址的转换,那就不就解决此问题了么:Qualcomm的强大这时候就体现出来了,人家的Wi-Fi芯片支持36bit的DMA MASK,地址访问范围从0~4G一下子提升到了0~64G,也就不需要进行地址转换了,只要使能Wi-Fi芯片PCIe接口的36bit DMA MASK完美解决问题。

复测的Rx TPU结果如下所示:

复测的CPU资源占用结果如下所示:

  • 26
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值