《PCIe AXI-Stream 架构（四）：你测到的可能不是 PCIe，是 Windows——主机侧测量的四个陷阱》

PCIe AXI-Stream 架构四你测到的可能不是 PCIe是 Windows——主机侧测量的四个陷阱上一篇《PCIe AXI-Stream 架构三直通延迟到底是 8 ns 还是 60 µs》本系列0 开篇 / 1 工程搭建 / 2 吞吐 / 3 延迟 /4 测量学本篇本篇数据来源《架构二TC04延迟测量与XDMA缓冲实测》v10§14~§18三跑长跑、电源 A/B、钉核双跑文章目录PCIe AXI-Stream 架构四你测到的可能不是 PCIe是 Windows——主机侧测量的四个陷阱[toc]1 先讲一个见了鬼的现象2 陷阱 ①吞吐不是延迟的函数2.1 延迟小 ⇒ 吞吐高是个想当然2.2 把首跑的六段拆开看2.3 怎么测的本节口径3 陷阱 ②RTT 的采样窗和吞吐的统计窗根本不是同一个窗3.1 现象3.2 修法蓄水池全段均匀采样4 陷阱 ③一个 ctypes 切片把 RTT 凭空测高一倍4.1 现象4.2 为什么4.3 铁律5 陷阱 ④主角所谓退化其实是两个 CPU 频率档5.1 先看一个反常识的细节快档的数字两轮逐位相同5.2 用排除法筛假设5.3 关键旁证RTT 和主机侧开销同向升降 ⇒ 共因在 CPU5.4 一次反被打脸的实验换来了更硬的证据5.5 给档位找独立物证CPU 实时频率5.6 怎么测的本节口径6 从相关到因果把线程钉在指定核上7 顺带一个有用的副产品53 µs 里哪部分随 CPU 频率变8 方法论三步法 一条判据要改写9 结论10 全系列回顾与收尾1 先讲一个见了鬼的现象前面三篇我们量到的都是很干净的数字FPGA 逻辑延迟8 ns、端到端往返60 µs、C2H 吞吐天花板133 MB/s。到了稳定性长跑这一关事情突然变得不讲道理了。稳定性测试的命令很简单连续跑 30 分钟每 5 分钟切一段每段算一次吞吐然后看最后一段是不是比第一段慢如果末段明显掉下来说明系统在退化。同一条命令跑了两遍结果方向相反第 1 段头 5 分钟第 6 段末 5 分钟判据末段 ≥ 首段 × 98%首跑67.01 MB/s快60.86 MB/s慢❌ 只有 90.8%复核57.30 MB/s慢66.99 MB/s快✅ 116.9%同一台机器、同一条命令、同一个工作点30 分钟里哪一段慢居然是随机的。首跑是越跑越慢复核是越跑越快。如果只看首跑你大概会得出一个听起来很合理的结论——“跑久了会热降频 / 内存泄漏所以性能退化”。但这个结论是错的。复核把它直接推翻了。这一篇不讲板卡讲测量本身。因为上面这个见了鬼根源全在主机侧而且是四个非常典型、几乎每个人都会踩的坑。看完这篇你以后不管测什么 PCIe 卡都不会再被骗。上图把三次长跑的各段帧周期画在一起。你会看到两条线在同样的两个高度之间来回跳——一条从高跳到低一条从低跳到高方向完全相反。这就是本篇要解释的全部现象。2 陷阱 ①吞吐不是延迟的函数2.1 延迟小 ⇒ 吞吐高是个想当然普通人心里都有一个默认公式延迟越小跑得越快吞吐就越高。在流水线里这句话大致成立很多帧同时在飞延迟低意味着单帧占用链路时间短。但在我们这个测试里它根本不成立。原因在测法本身。架构二测延迟用的是GEN_ECHO 一问一答详见篇 3主机组一帧请求 → 发出去 → 等板卡回帧 → 收到回帧 → 才发下一帧同一时刻只有一帧在飞这叫停等stop-and-wait。在停等模式下帧周期一帧花的总时间 1 / 帧率 吞吐 帧长 ÷ 帧周期而往返延迟 RTT只是帧周期里被计时器圈住的那一段。帧周期里还有一段在计时器之外的东西帧周期由两块组成里面有什么RTT被测的那段清事件 → 挂一次 DMA 读 → 写一帧请求 → 等完成事件 → 取结果主机侧开销计时器之外拼请求帧每帧新建 4096 字节 算校验和→ 拷贝回帧 → Python 循环 → 操作系统调度2.2 把首跑的六段拆开看首跑六段把周期和RTT并排放再相减得到主机侧开销段帧周期 µsRTT P50 µs主机侧开销 µs吞吐 MB/s160.5854.56.0867.01260.4653.07.4667.16362.6253.09.6264.84470.1058.112.0057.92567.4457.89.6460.20666.7252.614.1260.86现在再看那个见了鬼的疑问——“末段的 RTT52.6比首段54.5还小为什么吞吐反而更低”把周期增量拆开答案一目了然Δ周期 6.13 µs ΔRTT −1.90 µs ← RTT 确实变小了变快了 Δ主机侧开销 8.03 µs ← 但主机侧开销涨得更多吞吐下跌 100% 由主机侧开销那段解释而且还要额外吐出 1.9 µs 去抵消 RTT 的改善。一句话记住陷阱①吞吐 帧长 ÷ 帧周期而 RTT 只是帧周期的一部分。延迟和吞吐在停等模式下不是一根轴上的两个刻度是两根轴。你看到 RTT 变小只能说明其中一根轴变好了完全不能推断吞吐。2.3 怎么测的本节口径帧周期1 ÷ 帧率。帧率由这一段收到多少帧 ÷ 这段时长算出简单直接。RTT主机侧高精度计时器QueryPerformanceCounter发请求之前打 t0、收完响应之后打 t1相减。主机侧开销帧周期 − RTT。这不是直接量的是减出来的——所以它的正确性完全依赖 RTT 的口径是不是干净。而下面陷阱②③就是专门讲RTT 口径怎么才算干净。3 陷阱 ②RTT 的采样窗和吞吐的统计窗根本不是同一个窗这一条比陷阱①更隐蔽而且它是我自己写工具时犯的错值得单独讲。3.1 现象工具一开始为了省内存RTT 只留前 2000 个样本# 旧写法有偏iflen(samp)2000:samp.append(us)# 每段只收最前面的 2000 个样本算一下这两个窗差多少量采样范围实际覆盖的时间RTTP50 / P99每段最前面 2000 帧2000 ÷ 16500 ≈0.121 秒吞吐MB/s整段300 秒0.121 ÷ 300 0.04%。也就是说我拿每段前 0.04% 的瞬时延迟去解释整段的平均吞吐还指望它俩能对上——这不是测不准是两个数根本不在描述同一段时间。只要段内前快后慢首跑正是如此两个数字必然打架RTT 好看因为采的是快的那一小段吞吐难看因为算的是整段。这跟链接/板卡一点关系都没有纯粹是统计口径错了。3.2 修法蓄水池全段均匀采样正确做法是全段均匀采样用经典的蓄水池算法Algorithm R从第 k 个样本开始以m / k的概率把它替换进样本池m 池子大小。这样每个样本被留下的概率相等池子里的 2000 个样本就是整段的均匀代表。改完之后RTT 均和MB/s终于站在了同一个时间窗上。工具还额外整段累计了均 / 最小 / 最大从此归因才有意义。一句话记住陷阱②报一个平均延迟之前先问自己——这个平均值是覆盖哪段时间的如果它和你另一张性能表覆盖的时间不一样两个数就不能放在一起解释。4 陷阱 ③一个ctypes切片把 RTT 凭空测高一倍4.1 现象这个坑更程序猿。我们用 Python ctypes调驱动读数据读完拿到的是一个ctypes数组。一开始为了把它变成 Python 的bytes我写了databytes(buf[:n])# ❌ ctypes 数组切片结果 RTT 大了一截。A/B 对照同一个工作点、同一批帧写法4 KB 帧的 RTT 中位数bytes(buf[:n])98.8 µsmemoryview(buf).tobytes()52.4 µs白白多出 46 µs——比真正的 PCIe 往返还长。4.2 为什么buf[:n]对一个ctypes数组来说不是拷贝一段内存而是逐元素地生成 Python 对象每个字节都要新建一个 Pythonint、装进一个 Python 容器然后再转成bytes。4 KB 4096 个字节就是 4096 次对象创建 装箱。这个开销全在计时窗里面于是它被算进了 RTT。memoryview(buf).tobytes()则是一次性按内存块拷贝不生成任何 Python 对象快 42 倍。4.3 铁律陷阱③ 的两条铁律ctypes数组永远不要用buf[:n]要用memoryview(...).tobytes()或直接memoryview当缓冲区用。任何拷贝都必须在计时窗外做。计量的是设备的往返不是你转换数据格式的时间。这条和陷阱②是一对陷阱②是时间窗选错陷阱③是把不该计时的东西计了进去。两个都会让 RTT 失真但方向相反——一个让你误判哪段快一个让你整体偏高。顺便说一句这两处修完上位机的解析吞吐从 21.6 一路涨到 106.9 MB/s篇 2 §4 有完整的三处优化账。测量工具自己就是被测对象的一部分——一个慢的测量工具会把主机侧开销整体抬高让你误以为链路或板卡慢。5 陷阱 ④主角所谓退化其实是两个 CPU 频率档前面三个坑修完首跑越跑越慢和复核越跑越快这个核心矛盾依然存在。这才是本篇真正要解决的东西。5.1 先看一个反常识的细节快档的数字两轮逐位相同把两跑的各段周期并排你会发现它们不连续漂移而是只落在两个值附近档位帧周期帧率载荷吞吐首跑出现在复核出现在快档60.5 ~ 60.6 µs≈16500 帧/s67.0 MB/s段 1、2段 4、5、6慢档70.1 ~ 71.5 µs≈14000 帧/s57.0 ~ 57.9 MB/s段 4段 1、2中间态62.6 ~ 67.4 µs——段 3、5、6段 3而且快档的数值两轮几乎逐位相同首跑快档60.58 / 60.46 µs67.01 / 67.16 MB/s复核快档60.62 / 60.62 / 60.61 µs66.97 / 66.97 / 66.99 MB/s「6 段里恰好有 2 段跑到 60.6 µs」在两轮里都发生了数值几乎分毫不差。这不是漂移漂移是连续渐变的这是一个可复现的稳态工作点被反复命中。记一个判读要点离散档位 ≠ 连续漂移。“越跑越慢这种故事只适用于连续漂移一旦你看到数据只落在两个值上就该换思路——去问系统在两个稳态之间切换的开关是什么”。5.2 用排除法筛假设候选假设它预测什么实测判定CPU 热降频越跑越慢、单调、每次都会出现复核是越跑越快快档两轮都出现❌排除内存 / 句柄累积越跑越慢、单调同上方向随机❌排除Windows 后台 / 电源状态切换双向、随机、离散档位两档、方向随机、快档可复现✅存活5.3 关键旁证RTT 和主机侧开销同向升降 ⇒ 共因在 CPU复核跑比首跑干净正好可以看两个分量的方向。段 1 → 段 6Δ周期 −10.25 µs ΔRTT −5.18 µs ← PCIe 往返 驱动 中断唤醒 Δ主机侧开销 −5.08 µs ← 纯主机软件拼帧 / 拷贝 / 循环两者几乎五五开、同时下降。这条很关键主机侧开销是纯主机 CPU 代码拼请求帧、拷贝回帧、Python 循环里面没有任何 PCIe 事务如果只是链路变快变慢RTT会动、主机侧开销不该动现在两者同时动⇒共因在 CPU频率 / 抢占 / 线程被搬来搬去不在链路。5.4 一次反被打脸的实验换来了更硬的证据上面的推理指向CPU 频率。一个自然的想法是把 Windows 电源模式切到最佳性能让 CPU 一直跑最高频不就只剩快档了我去跑了10 分钟。结果②c 档位照旧打印—— 两档现象没有消失⇒慢档 被电源管理钉在低频这个说法被证伪但顺手出现了一个更反直觉的事实快档整个消失5/5 段全落在旧慢档区间70.05 ~ 72.51 µs。把 Windows 电源模式切到最佳性能这台机器的 PCIe 往返反而更慢了。原因设置里的最小处理器状态 100%会把所有核都顶到基准频率、摊薄了整个 CPU 封装的功耗预算于是单核的 turbo 反而冲不上去了。这条值得单独记住做性能测试时把电源调到最高性能未必是加分项可能直接把你要测的那个最优工作点抹掉。5.5 给档位找独立物证CPU 实时频率快慢两档到底是不是 CPU 频率造成的不能只看比例对得上就算数得直接读 CPU 的实时频率来对账。工具用纯ctypes零第三方依赖读本机每个逻辑核的当前频率CallNtPowerInformation。本机 14 个逻辑核逻辑核 14 个 cpu0, 1, 10, 11, 12, 13 : 4200 MHz cpu2 … cpu9 : 3600 MHz 4200 / 3600 1.167把它跟档位摆一起量数值核心频率比4200 / 36001.167慢档 / 快档 周期比干净档位71.19 / 60.901.169吻合差0.2%再跑第四次默认电源已恢复工具直接打出②d 频率快段(段1) 4200 MHz核1 慢段(段3) 3600 MHz核7 周期比 1.158 频率比 1.167 差 0.7% → 周期比 ≈ 频率比 → 两档 CPU 频率档帧周期随频率等比缩放⇒ 机制锁定帧周期几乎整体随 CPU 频率等比缩放。快档 循环线程恰好落在 4200 MHz 的核上慢档 落在 3600 MHz 的核上。注意连 RTT 也跟着变53 → 58 µs——因为DMA 完成 → 中断 → 延迟过程调用 → 唤醒线程这一整串全是 CPU 在跑它当然随频率缩放。这正是 §5.3共因在 CPU的定量版本。⚠️一个必须写进方法论的细节我一开始用的是全核平均频率结果它在本机恒为 ≈3857 MHz6 核 4200 8 核 3600 混在一起——根本不随档位动毫无诊断力。真正有信号的是循环线程所在那个核的频率也就是下面要说的落核频率。5.6 怎么测的本节口径量怎么得到的每核实时频率后台线程每 0.5 s 调一次CallNtPowerInformation(ProcessorInformation)读每个逻辑核当前 MHz落核段循环里每 0.1 s 调一次GetCurrentProcessorNumber()取本段最常驻的逻辑核直方图众数周期比 / 频率比差由工具自动算周期比与落核频率比相除差 ≤ 5% ⇒ 判两档 CPU 频率档⚠️落核是段级的众数不是逐帧真值。段内一旦发生核迁移这一段就是两档的加权混合——第四跑的段 4 正是如此落核显示 4200但周期 66.74 µs介于两档之间。要看干净的档位必须把线程钉住——这就是下一节。6 从相关到因果把线程钉在指定核上比例吻合到 0.7%这叫相关。要证明因果必须做控制变量实验把循环线程钉死在一个核上看档位是不是跟着核走。工具加了--affinity N用SetThreadAffinityMask把跑往返循环的那个线程钉到逻辑核 N。两跑唯一变量 钉在哪个核$pyC:\Users\haido\.workbuddy\binaries\python\envs\default\Scripts\python.exe# ① 钉到 4200 MHz 的核本机 核 1$pypcie_bench.py tc03--affinity 1--frame-len 4060--minutes 10--segment-min 2--csv tc03_aff_c1.csv# ② 钉到 3600 MHz 的核本机 核 3$pypcie_bench.py tc03--affinity 3--frame-len 4060--minutes 10--segment-min 2--csv tc03_aff_c3.csv结果项① 钉核 14200 MHz② 钉核 33600 MHz全段周期5 段60.24 / 60.30 / 60.37 / 60.38 / 60.28 →均 60.31 µs71.78 / 72.05 / 72.06 / 72.47 / 71.88 →均 72.05 µs段内波动0.2%1.0%载荷吞吐67.31 MB/s56.35 MB/sRTT P5053.0 µs58.2 µs主机侧开销6.77 µs12.62 µs落核4200核15/5 段3600核35/5 段②e 亲和性✅ 单档✅ 单档两跑各自波动只有 0.2% / 1.0%——钉核之后档位不再游走每一跑都塌成干净的一条水平线。这说明两档不是漂移是被 CPU 频率唯一决定的稳态。周期比72.05 / 60.31 1.1945标称频率比4200 / 3600 1.1667差2.4%。这个 2.4% 不影响因果判决方向一致、量级一致原因见下4200 / 3600是标称最大频率实跑时两个核的实际 turbo 未必正好落在这两个数上而且主机侧开销里含调度/抢占它对频率的敏感度高于线性实测涨了 86%远超 16.7%。⇒ 因果成立档位由线程落在哪个核唯一决定。一句话记住陷阱④你以为在测 PCIe其实测的是 Windows 调度器。帧周期里差不多八成的部分RTT 主机侧开销都在 CPU 上跑CPU 频率一抖你测的板卡性能就跟着抖。7 顺带一个有用的副产品53 µs 里哪部分随 CPU 频率变钉核双跑正好给了两个干净的工作点可以把 RTT 拆开Δ周期 11.73 µs ΔRTT 5.90 µs Δ主机侧开销 5.85 µs ← 几乎对半 RTT 53.0 → 58.2 只涨 9.8% 主机侧开销 6.77 → 12.62 涨 86%如果 RTT整体随频率缩放53.0 µs 该变成53.0 × 1.1667 61.8 µs实测只有58.2 µs。⇒ RTT 里含一段不随 CPU 频率变的成分。用两点线性拟合RTT L C·(f₀ / f)成分估计值含义L固定≈ 20 µs链路 驱动 XDMA 的物理往返不随主机 CPU 快慢变CCPU 相关≈ 33 µs中断 → 延迟过程调用 → 唤醒线程 → 拼帧 → 拷贝全在 CPU 上跑⇒架构二在 4.2 GHz 下的 53 µs 端到端 RTT ≈ 20 µs 固定往返 33 µs 主机 CPU 处理。这个拆法的价值它把主机侧开销从一句定性判断变成两个可以分别归因的数。以后换架构比谁更快就能拆成固定往返更短还是CPU 处理更少——而不是笼统地说这个快、那个慢。8 方法论三步法 一条判据要改写这一节是本篇的干货收口。上面所有折腾可以压成一个可复用的三步法步做什么用什么|① 发现离散档位| 先判断退化到底是连续漂移还是离散档位——只落在几个值上就是档位 |②c 档位贴着本跑最快段 ±3% 划快档 ||② 给档位找独立物证| 找一个和档位同向变化的系统量对账比例 |②d 频率周期比 vs 落核频率比 ||③ 推因果控制变量| 把线程钉死在指定核看档位是否随核走 |--affinity N②e 亲和性钉核后波动 5% |方法论的核心不是这三个数怎么算而是这个次序先确认现象是离散的否则退化的直觉会把你带偏再找独立物证不能只看比例对得上那是相关最后做控制变量才是因果。并且判据要跟着改。原来的稳定性判据是末段吞吐 ≥ 首段 × 98%在两档随机切换的平台上这条判据测的不是架构是运气——首/末段恰好落在哪一档判据就过或不过。应改写为末段吞吐 ≥ 最快档 × 98%也就是拿最优稳态档当基准或者干脆直接看工具打印的②c 档位行。⚠️ 一条边界钉核后有 2~3% 的测量抖动所以②e的阈值放宽到5%而真实两档间隔约16%有 3 倍以上余量。阈值不是越紧越好——紧过测量噪声就会把正常的抖动误判成还有别的因素。9 结论把四个陷阱串起来其实是一句话测量 PCIe 端到端性能时一半以上的性能变化可能来自测量主机而不是被测板卡。四个陷阱各自的病根#陷阱病根记法①吞吐不是 RTT 的函数停等模式下吞吐由帧周期决定RTT 只是其中一段别用延迟推吞吐②采样窗 ≠ 统计窗RTT 只采 0.04% 的时间却在解释 100% 的吞吐报平均值先问覆盖哪段③ctypes切片逐元素生成对象白白多 46 µs用memoryview拷贝出计时窗④两档 CPU 频率档帧周期八成在 CPU 上跑随频率缩放测前先钉核、先锁频架构二Streaming 直通的完整画像本系列到此收口维度数字口径延迟FPGA 逻辑8 ns2 拍与帧长无关ILA 逐拍铁证篇 3延迟端到端 RTT60.3 µs 4.2 GHz72.0 µs 3.6 GHz≈ 20 µs 固定往返 ≈ 33 µs 主机 CPU§7吞吐LOOP 直通98.6% 线速4132 B 帧 → 3942.7 MB/s上板首次贯通吞吐GEN_ECHO 停等67.3 MB/s 4.2 GHz受主机 CPU 限非链路限吞吐天花板C2H≈ 133 MB/s速率分频扫描锁定篇 2稳定性91 708 725 帧零错帧、零丢帧、零超时六跑合计做直通架构选型时的顺序先问主机能不能钉核 锁频再问链路多快。否则你测到的是 Windows 调度器不是板卡。这一篇也是整个系列的方法论收尾。前面三篇量到的所有数字——吞吐、延迟、稳定性——都建立在这套测量纪律之上没有它那些数字里就混着主机的抖动而你分不清哪个是板卡的、哪个是 Windows 的。10 全系列回顾与收尾到这里架构二Streaming 直通的五篇就讲完了。回顾一下这条线篇回答的问题一句话结论0 开篇这个实验在测什么、数字怎么来别拿链路 4 GB/s当系统 4 GB/s先立测量口径1 工程搭建一个 XDMA 直通工程怎么从零搭起来9 个 BD 组件 5 个自写模块数据/控制流一次讲清2 吞吐为什么只有 133 MB/sFPGA 侧 98.6% 线速卡在 C2H 非 posted 读往返3 延迟8 ns 还是 60 µs8 ns 是 FPGA 逻辑60 µs 含链路往返 主机 CPU4 测量学本篇为什么稳定性忽好忽坏你测到的可能不是板卡是 Windows 调度器下一篇架构三 / 架构一按计划接下来开工多通道架构架构四——把 XDMA 的 C2H 通道从 1 条加到 2 条本器件 7 系列 Gen2 IP 的通道数上限就是 2看能不能把那133 MB/s的天花板顶开。到时候这一篇学到的先钉核、先锁频会直接用上——否则你根本分不清加通道带来的提升和主机今天心情好。本系列数据与工具全部图由脚本生成tools/make_csdn_figures_p4.py改参数即可重出上位机pcie_bench.py的tc03子命令内置了本篇讲的全部判据②b 归因/②c 档位/②d 频率/②e 亲和性可直接复现。