PCIe Gen6 SSD 到底难不难测？

如果只是看规格表，好像并不复杂：

64 GT/s、PAM4、x4、E1.S/E3.S，把盘插上去，跑个 FIO，看看能不能达到二十几个 GB/s，不就完了吗？

但真正进入研发验证现场以后，会发现问题远没有这么简单。

有时候最麻烦的甚至不是：

“Gen6 Link起不来。”

而是：

Link明明已经稳定工作在Gen6 x4，系统也能正常识别SSD，可一旦中间增加PCIe Switch，性能就掉了10%、20%，甚至更多。

这时候到底是谁的问题？

是 Switch？

是 Cable？

是转接板？

是 Gen6 Signal Integrity？

还是 SSD Controller 本身与 Switch 之间的 Flow Control 出现了问题？

最近，我们围绕一套 PCIe Gen6 SSD 测试环境和成都一个PCIe 6.0 E3.S SSD研发客户做了一次四十多分钟的技术交流。

讨论从最开始的：

PCIe Gen6 Switch；

E1.S/E3.S Adapter；

CXL x8/x16；

Flow Control Credit；

协议分析仪抓包；

FIO 性能对比；

Gen6 8-Bay JBOF；

Power Cycle；

PAM；

Fault Injection；

以及 Gen6 环境下为什么不建议反复人工插拔 SSD。

看起来问题很多，但整场交流其实围绕着一条非常清晰的主线：

一套真正可用于Gen6 SSD研发的测试环境，绝不能只验证“能不能Link Up”，还必须验证设备进入真实Switch拓扑以后，协议、流控、性能和可靠性是不是仍然正常。

一、交流一开始碰到的第一个现实问题：Gen6 SSD样品本身就不好找

我们目前也在看能否找到一块 PCIe Gen6 x4 E1.S SSD，主要是配合现有 Gen6 测试工具做实验、拍摄高清视频和搭建演示环境，包括：

PCIe Gen6 Protocol Analyzer；

Protocol Tester；

SSD Validation System；

Power / Fault Injection；

Gen6 Switch及各种Adapter。

目前市场上Gen6 SSD仍旧买不到，当然准确的理解应该是：

特定型号、特定Form Factor、能够自由用于研发测试的样品获取仍然困难，并不是市场上完全没有量产Gen6 SSD。

截至目前，Micron 官方的 9650 已经是一款 PCIe Gen6 x4 数据中心 SSD，提供 E1.S 和 E3.S，官方最高顺序读取达到 28 GB/s、随机读取达到 5.5 MIOPS；Micron 也已经明确表示 9650 正在量产出货。

Samsung 也在 2026年7月8日正式宣布开始量产 PCIe 6.0 企业级 SSD PM1763。

所以现在行业已经从：

“有没有Gen6 SSD”

逐步进入：

“我能不能方便地拿到我要的Gen6 SSD，并放进自己的验证环境里反复折腾”

这个阶段。

这两件事完全不是一回事。

二、接下来客户问了一个很实际的问题：Switch卡顶部到底该买哪种转接卡？

大约三分钟后，话题开始进入环境搭建。

客户已经在考虑使用 我们Saniffer公司销售的Gen6 PCIe Switch Card。

当前 Serial Cables 基于 Broadcom Atlas 3 的 Gen6 Host Card，正式产品版本提供：

4个Gen6 x8 MCIO下行接口；

以及：

1个Gen6 x16 Straddle Mount接口；

整张卡可以向 Switch 下游提供 64 Lane 的 Gen6 Connectivity。更重要的是，这类架构甚至允许上游先使用现有 Gen5 Host，而在 Switch 下游先建立 Gen6 Endpoint 验证环境。

于是问题来了：

如果我现在只是测一块：

PCIe Gen6 x4 E1.S SSD，

到底买 x8 Adapter 就够了，还是干脆买 x16？

三、如果今天只做SSD，x4够；但如果明天要做CXL，思路马上就变了

现场的判断非常直接。

普通 PCIe Gen6 NVMe SSD，无论是 E1.S 还是很多 E3.S 产品，常见数据接口还是：

PCIe Gen6 x4。

所以仅从 SSD 来看，使用能够承载 x4 Device 的转接方案已经足够。

但客户的实验室未来还有一个可能性：

CXL。

一旦开始测试 CXL Memory Device，尤其是更高带宽的 Type 3 Memory Device，x8甚至x16就会变得很常见。

因此现场建议是：

如果x8和x16方案投资差异可以接受，而未来明确可能做CXL，那么尽量不要把实验环境一开始就锁死在x4。

交流中因此专门讨论了：

Gen6 x4 SSD；

CXL x8；

CXL x16

三种设备如何尽量通过一套基础测试环境覆盖。

客户最后也更倾向于给未来留出 x16 的扩展能力。

这其实是搭实验室时非常值得注意的一件事：

不要只按照今天桌子上的DUT买设备。

尤其是 PCIe Gen6/CXL 环境，一块 Switch、一套 Cable、一批 Adapter 很可能会用很多年。

今天测的是：

Gen6 x4 SSD；

明年可能就变成：

CXL x8 Memory Device；

后面甚至可能出现：

CXL x16 AIC。

如果底层拓扑提前留好余量，后面会轻松很多。

四、E1.S和E3.S看起来都是EDSFF，但别忘了机械结构也要匹配

接下来讨论进一步落到了 EDSFF 的机械结构，这主要涉及到 E1.S / E3.S 等不同EDSFF转接卡及对应的Holder/Bracket。

同一张高速电气 Adapter，很多时候 PCB 主体设计可能非常接近。

但：

E1.S的长度、宽度、固定方式；

E3.S的机械尺寸；

不同厚度的Device

并不相同。

因此产品往往会通过不同的：

SSD Drive Holder / Bracket

把 DUT 正确固定。

现场甚至讨论了一种实验室临时省成本的方法：

如果偶尔才测试另一种尺寸，可以拆掉原本的固定支架，再用临时机械方式固定。

不过如果是正式研发环境，我并不建议把这种临时办法当作长期方案。

到了 PCIe Gen6，机械固定本身已经不仅仅是“盘别掉下来”。

Connector mating；

PCB受力；

接触稳定性；

线缆弯曲状态

都可能进一步影响高速链路的重复性。

所以如果某一种 Form Factor 会被高频使用，最好还是配置真正匹配的 Holder。

五、这里现场有一句话需要稍微纠正：“CXL就是PCIe上层协议”

会议进行到7分钟左右，大家讨论：

同一套 Adapter 能不能既接 NVMe SSD，又接 CXL Memory Device？

现场为了方便理解，用了一个比较口语化的说法：

“CXL也是PCIe上层，就像NVMe一样。”

当然，CXL并不能简单等同于“像NVMe那样的PCIe上层协议”。

CXL本身定义了不同的协议路径，其中包括：

CXL.io

以及：

CXL.cache / CXL.mem。

CXL.io承载和PCIe相关的设备发现、配置等语义，而CXL.cache/CXL.mem则负责缓存一致性和内存语义。

CXL 3.0把链路速率提升到 64 GT/s，可以基于PCIe 6.0级别的高速物理基础设施运行，并扩展到最多x16 Lane。

所以为什么一块好的 EDSFF Adapter 可以同时宣称支持：

PCIe；

NVMe；

CXL？

原因并不是：

“NVMe和CXL是一回事。”

而是：

对于纯物理转接设备来说，只要它满足对应的Connector、Lane数量、Sideband以及Gen6 Signal Integrity要求，本身并不需要理解上层跑的是NVMe还是CXL.mem。

它做的主要工作仍然是把物理链路完整送过去。

这个概念一定要分清。

六、大约9分半，真正有意思的问题出现了：Link能起来，但性能就是上不去

前面的讨论还属于“怎么买设备”。

到了大约9分半，客户突然提出了一个真正值得分析的现场问题。

他们之前已经做过一套类似环境：

SSD连接PCIe Switch；

系统能够正常枚举；

链路训练也没有明显问题。

换句话说：

Link是起来的。

但一跑性能：

就是跑不上去。

这其实是高速PCIe验证中一个非常典型、也非常容易误判的问题。

很多工程师看到：

Gen6 x4；

Link Up；

系统识别正常；

lspci也正常，

第一反应会觉得：

“PCIe已经没问题了。”

其实远远不够。

Link Up只能说明双方建立了链路。

它不能证明：

协议效率正常；

Flow Control正常；

Buffer没有堵塞；

大量数据传输时没有Replay；

SSD Controller和Switch之间没有互操作问题；

更不能证明最终FIO一定能跑满。

所以：

“能建链”和“能跑满性能”是两个完全不同的验证阶段。

七、我们以前在Gen5时代，其实已经碰到过几乎一模一样的问题

为了说明这一点，现场回顾了一个 Gen5 时代碰到过的案例。

这里我把具体客户和主控型号隐去，只保留技术现象。

当时某企业级 Gen5 SSD：

直接通过 Adapter 接到 CPU Root Complex；

跑 FIO 或性能软件时，

读写性能都正常。

但把拓扑改成：

CPU → PCIe Switch → SSD

以后，

其中一个方向的性能明显下降，大约损失一个不容忽视的比例，~8%。

更奇怪的是：

另一个方向却没有同样幅度的下降，反而单纯从数字来看还高了一丁点（可以忽略）。

于是第一反应当然是：

Switch有问题？

但后来拿其他已经比较成熟的 SSD 方案，在同一套 Switch 环境里做对比测试，却没有出现相同现象。

最终排查方向落到了：

特定SSD Controller与Switch之间的交互。

这个案例特别值得记住。

因为它告诉我们：

“我的SSD直连CPU性能没问题”，并不能证明这块SSD进入真实服务器和存储系统以后也一定没问题。

八、为什么企业级SSD尤其不能只做“CPU直连测试”？

原因其实很简单。

真正的数据中心系统不一定永远是：

CPU → SSD。

大量实际拓扑可能是：

CPU

↓

PCIe Switch

↓

Backplane / JBOF

↓

SSD

甚至可能继续加入：

Retimer；

Redriver；

Cable；

多级Switch。

所以一块企业级 SSD 最终面对的“对端”，很可能并不是 CPU Root Port。

而是：

PCIe Switch Downstream Port。

会议中也特别强调：

如果某SSD Controller直连CPU完全正常，但进入一个主流PCIe Switch拓扑以后长期存在性能异常，那么对企业级产品来说，这依然是必须解决的互操作问题。

因为最终客户不会接受：

“我们和CPU直连的时候没问题。”

客户只会问：

“为什么别人家的盘插在我的服务器里正常，你家的不正常？”

这就是工程问题。

九、Switch本身会增加Latency，但“多一个Switch”不等于吞吐量必然掉20%

现场随后讨论到：

增加 PCIe Switch 当然不可能完全没有代价。

数据包从 CPU 出来以后进入 Switch：

需要接收；

解析；

查找转发目标；

经过内部 Buffer/Fabric；

再从对应 Downstream Port 发出去。

所以：

Latency必然会增加。

交流里现场还提到了一个大致延迟数字，但讲话人自己也明确表示记忆并不确定，所以这里不引用具体数值。

真正要区分的是：

Latency增加

和

Sustained Throughput明显下降

不是一回事。

对连续大流量传输来说，如果：

Switch带宽足够；

上行没有成为瓶颈；

链路没有大量错误；

Flow Control正常；

SSD能够及时处理数据，

那么仅仅多经过一级 Switch，不应该简单推导出“带宽必然下降10%～20%”。

如果真掉了这么多，

就值得继续往下查。

十、查什么？现场首先想到的不是重新跑Benchmark，而是抓Flow Control

大约15分钟时，整个交流进入了最核心的一段。

如果：

Link Speed正常；

Link Width正常；

没有明显掉速、掉Lane；

但经过Switch性能下降，

应该怎么办？

现场给出的方向是：

抓PCIe协议。

而且不能只随便看几个 TLP。

重点看：

Flow Control。

SerialTek 当前 Kodiak PCIe 6.0/CXL Protocol Analyzer 的 Protocol Reports 里，官方直接把：

Flow Control Update Delay；

Exhausted Flow Control Credits；

Unexpected Flow Control State Transition

列为可以自动识别的异常/警告项目。

为什么 Flow Control 会影响 SSD 性能？

SerialTek PCIe 5.0和6.0 协议分析仪提供的针对Flow control分析的专家分析功能是业内独有的分析PCIe链路双方沟通性能不稳定创新功能。

这件事其实可以用一个很形象的例子来解释。

十一、把PCIe Flow Control想象成“仓库还有几个空货位”

PCIe不是发送端想发多少Packet就随便发多少。

接收端内部有 Buffer。

所以它要通过 Credit 告诉发送端：

“我现在还能接多少数据。”

可以把接收端想象成一个仓库。

Credit就像：

空货位数量。

如果仓库告诉货车：

“我还有100个空位。”

发送端就可以继续发。

但如果 Credit 用完：

发送端即使有一堆数据准备发送，

也必须等。

这里要把交流中的一个口语化说法稍微修正解释一下。

现场为了方便理解，说：

“SSD告诉Host，你慢点发。”

从协议机制来说，更准确的表达应该是：

Receiver通过Flow Control机制维护、更新可用接收Buffer Credit；Transmitter只有在拥有足够Credit时才能继续发送对应类型的数据。

如果：

Credit长时间耗尽；

Credit Update不及时；

或者某一方向的Buffer管理效率不好，

那么发送端自然会出现等待。

于是你从 FIO 上看到的结果就是：

吞吐量掉下来了。

十二、所以性能掉20%，有时候Link层看起来反而“一切正常”

这也是这一类故障最容易让人困惑的地方。

你去看：

Gen6 x4——正常；

LTSSM——正常；

没有掉到Gen5；

没有掉成x2；

操作系统——正常；

NVMe Drive——正常识别。

甚至：

没有明显 CRC Error。

但：

FIO就是比直连CPU低20%。

为什么？

因为问题可能根本不是：

“Packet传错了。”

而是：

“Packet在等。”

例如写方向：

Host/Switch不停往SSD发数据；

但SSD Controller内部：

Buffer；

NAND调度；

Firmware；

Data Path

处理不够快。

Receiver可用Credit越来越少。

于是前端发送被迫等待。

读方向也是一样。

如果 NAND → Controller → PCIe Packet这一整条数据路径不能及时把数据准备出来，那么Host端看到的就是：

我要数据，但你总让我等。

交流里正是通过这样的方式解释：

为什么 Controller Buffer Architecture 和 Flow Control 最终可以直接表现成 SSD Benchmark 的带宽下降。

十三、但千万别一看到性能差就认定“肯定是Flow Control”

这里必须再往下分一层。

性能下降至少有两条完全不同的故障路径。

第一条：Signal Integrity不好

比如：

Connector；

Cable；

Adapter；

PCB；

SSD本身的PHY；

Switch Port

某一段 Margin 太差。

结果出现：

CRC；

FEC相关错误；

Replay；

Retrain；

甚至Recovery。

这些东西当然会吃掉有效带宽。

交流中也明确提出：

如果 SSD PCB 或信号路径不好，可以从 Analyzer 或 Switch Port 的 Error/Telemetry 中进一步寻找证据。

第二条：信号很好，但协议效率出了问题

也就是：

Link很稳定；

没有明显链路错误；

但是：

Credit长期不足；

Flow Control Update异常；

某个方向经常等待。

这种情况才应该重点往：

Controller；

Firmware；

Buffer Architecture；

Switch互操作

方向调查。

所以正确顺序不是：

“性能低→Flow Control有Bug。”

而是：

先把Signal问题排除，再研究协议效率和Flow Control。

十四、PCIe Gen6时代，这一步尤其重要，因为PAM4本来就带来了全新的错误处理机制

PCIe 6.0达到 64 GT/s，采用 PAM4，并引入了固定大小的 FLIT、低延迟 FEC 和更强的 CRC 保护。

其中一个很重要的机制是：

接收端先做 FEC Decode。

如果是 FEC 可以纠正的错误，可以直接恢复。

然后再做 CRC 检查。

如果 CRC 仍然失败，则可以通过 NAK 触发 Replay，让对应 FLIT 重新传输。

所以 Gen6 调试时必须建立一个新的意识：

Link Up不代表Bit Error为零。

而：

系统还能正常工作，也不代表链路没有在花代价纠错。

如果错误率已经高到频繁触发Replay，

性能当然可能受到影响。

因此在“Switch后性能下降”这类问题上，

必须先回答：

到底是因为链路正在不断修错、重传，还是链路非常干净，只是两端在频繁等待Credit？

这两种问题的解决方向完全不同。

十五、现场给出的抓包方法很具体：Analyzer要串在Switch和SSD之间

如果问题出现在：

CPU → Switch → SSD

这个拓扑，

Analyzer应该放在哪里？

现场建议很明确：

放在：

Switch Downstream Port

和

SSD

之间。

例如：

CPU

↓

Gen6 Switch

↓

PCIe Protocol Analyzer + E1.S Interposer

↓

E1.S SSD

为什么放这里？

因为我们真正想知道的是：

Switch和SSD Controller两个人之间到底在说什么。

谁在等谁？

Credit什么时候耗尽？

哪个方向被Hold？

有没有Error？

有没有Replay？

这样问题才能直接定位。

十六、而且抓包不能等FIO开始以后才按“Start”

这一点特别重要。

很多工程师测试性能问题时，会这样做：

系统启动；

Linux起来；

SSD识别；

准备FIO；

打开Analyzer；

开始抓包；

跑FIO。

对于单纯看数据阶段也许够。

但如果你要研究 Flow Control，就不够。

现场特别强调：

Analyzer要在系统开机之前就开始Capture。

因为 PCIe Link 初始化期间双方就会建立 Flow Control 相关状态和 Credit。

这一段必须保留下来。

一个更完整的抓包流程应该是：

Analyzer开始Capture；

↓

Host Power On；

↓

PCIe Link Training；

↓

Device Enumeration；

↓

进入Linux；

↓

确认NVMe Device；

↓

运行与故障完全相同的FIO；

↓

性能下降复现；

↓

Capture停止；

↓

分析Error + Flow Control + Performance Timeline。

这样得到的Trace才真正有价值。

十七、Gen6数据量太大，怎么保证关键那几秒没有被冲掉？

这又是一个很实际的问题。

PCIe Gen6 x4数据量非常大。

如果无脑：

“从开机一直Full Capture”，

Trace Buffer可能很快就被高速FIO数据灌满。

现场因此给出了一个很实际的做法。

当前 Kodiak Enterprise Edition 官方规格是 256 GB Trace Buffer。

现场测试经验里，可以按双向分别分配足够的 Buffer；针对这类问题，并不一定非要把所有 Buffer 全部用完。

交流中建议的例子是：

每个方向约20 GB；

合计约40 GB；

并设置：

任一方向Buffer抓满就自动Stop。

为什么？

因为系统从Boot到Linux、再到执行FIO之前，真正高速的数据量通常并没有压力测试阶段那么夸张。

真正要保护的是：

FIO开始以后那一小段最有价值的数据。

如果还靠人眼看到性能掉了再去按停止：

往往已经来不及了。

十八、真正跑FIO时，也不能只说一句“我们都是跑FIO”

这是整个故障复现里另外一个非常容易被忽略的地方。

两个团队都说：

“我们跑FIO。”

完全不代表测试条件一样。

至少应该固定：

Read / Write / Randread / Randwrite；

Block Size；

Queue Depth；

Numjobs；

IO Engine；

Direct IO；

Runtime；

File/Namespace范围；

CPU Affinity；

NUMA；

测试前盘状态；

是否预处理；

甚至散热条件。

交流最后双方也专门达成一个共识：

如果后面要做 A/B 复现测试，

尽量拿到完全相同的测试命令。

否则一边说：

“Switch后只有22GB/s。”

另一边说：

“我们这里27GB/s。”

可能最后只是两边的：

QD；

Block Size；

IO Pattern

根本不一样。

这种比较没有意义。

十九、最有效的办法之一：拿一块Golden Drive做A/B Test

除了Analyzer，

现场还反复强调了一种非常朴素但有效的方法：

换盘。

拓扑完全不变：

同一台Host；

同一张Switch；

同一根Cable；

同一个Adapter；

同样的FIO命令；

同样的Slot；

只换SSD。

例如：

DUT A：正在研发的SSD

Switch后：

性能明显下降。

DUT B：已验证成熟的参考SSD

Switch后：

性能基本正常。

那么调查范围立刻缩小。

这不能100%证明：

“DUT Controller一定有Bug。”

但是至少可以非常有力地告诉你：

Switch本身并不是在所有SSD上都造成同样的性能损失。

这时候就应该重点去看：

DUT Firmware；

Controller；

Flow Control；

Buffer；

PHY；

PCIe Transaction行为

之间的差异。

交流中正是用以前的 Gen5 实际案例来说明这种方法。

二十、所以“Switch兼容性”这个词其实也要谨慎使用

现场有一句话说得很有意思：

不能简单叫：

“兼容性问题。”

因为：

链路是通的；

Gen6 x4也起来了；

系统也没有掉盘。

那这种问题究竟叫什么？

更准确地说，它属于：

Interoperability / Performance Interaction。

或者：

Controller与Switch拓扑下的协议/性能互操作问题。

这比一句：

“Broadcom Switch不兼容”

或者：

“SSD不兼容Switch”

更加准确。

因为最终到底要改哪一边，

需要抓完Trace才知道。

可能：

SSD Firmware可以解决；

Controller Buffer策略可以调整；

某些Credit相关参数或实现需要分析；

也可能最后发现其实还是Signal问题。

在没有证据之前，

不能先给任何一方“定罪”。

二十一、讨论到25分钟后，客户开始认真考虑下一步：是不是干脆买一个Gen6盘柜？

解决单盘以后，

自然会走向多盘。

客户提到，下一轮可能考虑一套“盘柜”。

这里所谓的盘柜，对应现在更准确的产品概念是：

Gen6 JBOF——Just a Bunch Of Flash。

Serial Cables 当前的 Hydra 就是一套 8-Bay Passive Gen6 x8 EDSFF JBOF，支持 PCIe/NVMe/CXL，当前官方列出的Device Form Factor包括 E3.S 2T、E3.L 和 E3.L 2T。

这个设计有一个很有意思的特点：

每个Bay的物理链路可以到x8。

所以今天你可以插：

Gen6 x4 NVMe SSD；

未来也可以用于：

更宽链路的CXL Device。

这正好和前面“实验室别只为今天的x4 SSD设计”呼应起来。

二十二、Switch到8个Bay，是怎么把线接出来的？

现场随后花了不少时间讲这个拓扑。

Gen6 Switch Card有多个 x8 MCIO接口。

如果接普通单盘，可以：

MCIO x8

↓

拆成两个Gen6 x4

↓

分别连接两个SSD。

而如果接8-Bay JBOF，

则通过相应的高速Cable把Switch的多组Lane送到JBOF Backplane/Paddle Card，再分别进入各个Bay。

因此整个环境可以逐渐变成：

Host

↓

Gen6 Switch

↓

多路MCIO

↓

Gen6 JBOF

↓

8× E3 Device

这已经不再是一张桌子上插一块SSD的环境。

而是越来越接近真正服务器和存储系统中的拓扑。

这对于企业级 SSD 验证尤其重要。

二十三、盘柜真正的价值并不是“整齐地放8块盘”，而是自动化

如果只是为了：

“把8块SSD放得整齐一点”，

其实没必要花钱买专业JBOF。

它真正的价值在于：

软件可控。

Hydra当前官方支持：

Per-Slot Power Sequencing；

Hot-Plug Simulation；

Presence Detection；

Temperature Monitoring；

Fan Control；

Power Telemetry；

Python UI；

CLI；

API。

也就是说，测试程序可以做这样的事情：

Slot 1上电；

等待Enumeration；

跑FIO；

记录结果；

Slot 1掉电；

等待5秒；

重新上电；

循环100次；

然后自动切换Slot 2。

这跟工程师站在机器前：

拔盘；

插盘；

拔电源；

插电源

完全不是一回事。

二十四、而且现在JBOF还可以继续加入PAM和Breaker

会议当天讨论时，某些扩展模块的价格和交付状态还需要继续向原厂确认，所以现场没有把它们写死。

不过截至目前，Serial Cables Hydra 官方产品页已经明确列出了与 Quarch 的集成能力：

可选：

Quarch PAM - 功耗和sideband边带信号记录、回溯和分析；

以及：

Quarch Breaker - hotplug热插拔 + fault injection底层故障注入。

PAM侧重于：

Voltage；

Current；

Power；

以及相应信号的观测。

Breaker则可以进一步做：

更精细的Power / Signal Switching和Fault Injection。

这样整套系统就可以逐渐从：

“8块盘一起跑FIO”

升级成：

“8块盘自动化跑Power Cycle、Fault Injection、功耗和协议验证”。

这才是研发型 JBOF 的真正意义。

二十五、Power Cycle和“真正的异常热拔插”不要混为一谈

这部分交流里还有一个很好的讨论。

如果JBOF通过MCU控制某个Slot掉电，

它可以很好地完成：

Power Cycle；

Power Sequencing；

自动化上下电测试。

但这和：

真正把Connector上的Power、Sideband甚至Data Lane按指定时序物理断开

仍然不是完全一回事。

所以：

普通JBOF Slot Control

和

Quarch Breaker这种Fault Injection工具

应该理解成两个层次。

前者解决：

自动化。

后者解决：

可控地制造异常。

实际做 PLP、Surprise Removal、Signal Glitch 或非常精细的Hot-Swap Fault测试时，这个区别非常重要。

二十六、为什么到了Gen6以后，越来越不建议工程师靠手拔盘做几百次测试？

会议30分钟以后，又聊到了一个非常“实验室”的问题：

能不能直接：

拔出来；

插进去；

拔出来；

再插进去？

偶尔当然可以。

但如果要做：

几十次；

上百次；

甚至大量Regression，

就不应该主要依靠人工反复插拔。

现场给出的理由有两个。

第一：

Connector本身存在机械磨损。

第二：

到了Gen6以后，一点点接触状态变化都有可能进一步影响Signal Integrity。

这里交流中出现了一些具体插拔次数、镀金厚度数字，但没有足够资料证明它们适用于所有Connector，所以不把这些数字作为通用规范引用。

真正需要记住的是：

高速测试环境本身也会老化。

有时候你测着测着发现：

昨天Gen6稳定；

今天突然Error变多。

问题未必是DUT变坏。

也可能是：

Adapter；

Connector；

Cable；

Interposer

经过长期插拔以后，环境本身发生了变化。

这就是为什么好的Validation Lab会尽量提高测试环境的Repeatability。

二十七、Gen6调信号不能只盯着“有没有掉链”

交流后面还谈到一个非常重要的调试思路。

如果 Analyzer 能够把：

Link Error；

FEC相关状态；

CRC；

Replay；

Training状态

和协议Trace结合起来，

你就可以在调节Channel、EQ或测试Fixture时看到：

链路到底是在变好，还是仅仅“还没掉”。

当前 SerialTek Kodiak 官方资料明确支持 PCIe 6.0 64 GT/s PAM4、FLIT解码，并可识别 FEC 和 Link Training 相关问题；其 Protocol Reports 也可以标记 DLLP CRC、Link CRC、Flow Control Credit等异常。

这比只看：

LnkSta:Speed64GT/s,Width x4

有价值得多。

因为：

64GT/s x4只是状态。

真正的工程问题是：

它以多大的Margin工作在这个状态？

二十八、交流里提到的“Correctable / Uncorrectable”也需要稍微严谨一点

现场为了方便讲解，把 Gen6 Error 简化成：

Correctable Error；

Uncorrectable Error。

这种说法适合理解趋势，但如果严格按照 PCIe 6.0 的机制，应该结合：

FEC；

CRC；

Replay

来看。

PCI-SIG 官方说明：

每个 FLIT 都有 CRC 和 FEC保护；

FEC首先纠正能力范围内的错误；

随后检查CRC；

如果CRC仍然失败，可以发送NAK并触发Replay。

所以真正调试时，并不存在一个放之四海而皆准的：

“低于1000个就合格”

或者：

“低于10000个就可以”

这样的阈值。

正式验证时应该依据：

PCI-SIG规范；

PHY/Controller Vendor要求；

产品自身Validation Criteria

确定Pass/Fail。

而不是凭一个经验数字判断。

二十九、34分钟以后，客户又回到了一个现实问题：Analyzer太贵

讨论到这里，客户也很实际地表示：

Protocol Analyzer价格较高，

短期可能无法购买该设备做问题定位。

这是完全合理的。

因为如果现在的问题只是：

“Switch后为什么性能掉？”

那么先用 Analyzer 把问题性质搞清楚，

比马上采购更重要。

一旦确认团队以后长期要做：

Gen6 SSD Controller；

Firmware；

Switch互操作；

CXL；

Protocol Compliance；

各种偶现问题Debug，

再考虑建立自己的Analyzer环境，逻辑就完全不同。

三十、最后又出现一个很典型的争论：Gen6到底用Cable好，还是Adapter Board好？

会议最后几分钟，大家又绕回物理连接。

现场转述了一个来自原厂FAE的观点：

在相同延伸距离下，他更倾向使用高质量高速Cable，而不是让信号全部在较长PCB Trace上走，理由是某些场景下Cable的损耗可能更容易控制。

但这句话绝对不能扩展成：

“Gen6永远是Cable比PCB好。”

真正比较时必须看完整Channel：

PCB材料；

Trace Length；

Via；

Connector；

Cable；

Adapter；

Insertion Loss；

Return Loss；

Crosstalk；

Tx/Rx Equalization

全部加起来。

一张只有几厘米的优质Adapter，

当然可能比一根很长的Cable更容易。

反过来，

一段经过精心设计的低损耗Cable，

也可能比很长的PCB走线更有优势。

所以最靠谱的判断方式不是：

“板还是线？”

而是：

整个Channel Budget到底是多少？

三十一、最终双方决定：别继续争论，直接做同条件A/B Test

会议最后形成了一个很工程化的结论。

我们这边后续如果拿到那块 Gen6 x4 E1.S SSD，

就搭建测试环境。

客户那边尽量提供：

他们原来的测试命令和条件。

我们用尽量相同的：

DUT类型；

FIO参数；

Host；

Switch；

Adapter/Cable

做一轮对比。

如果：

Switch + Adapter性能正常；

Switch + Cable也正常，

说明整个生态基本没问题。

如果：

某一种连接明显下降，

继续查SI。

如果：

Golden Drive正常；

客户自己的DUT明显下降，

重点抓：

Controller / Flow Control。

如果：

所有盘全部经过Switch都下降，

再回过头研究：

Switch配置；

Host带宽；

上行链路；

拓扑；

测试方法。

这比所有人在会议室里猜：

“是不是Switch有问题？”

有效得多。

三十二、把整场交流整理下来，其实形成了一套很实用的Gen6 SSD性能故障排查方法

以后再遇到：

“SSD直连CPU很快，一过Switch就慢。”

可以按照这个顺序来。

第一步，看Link。

确认：

Gen6还是Gen5？

x4还是x2？

有没有Retrain？

有没有频繁Recovery？

第二步，看Error。

重点判断：

FEC；

CRC；

Replay；

Link Error

是不是在Switch拓扑下明显增加。

如果是：

先查Signal Integrity。

第三步，做Golden Drive A/B。

同一环境换一块成熟参考盘。

如果参考盘正常：

DUT调查优先级明显提高。

第四步，抓完整Boot Trace。

不要FIO开始以后才抓。

要把：

Link Training；

Enumeration；

Flow Control初始化；

进入OS；

FIO

整段留下来。

第五步，重点看Flow Control Credit。

如果没有明显链路错误，

却出现：

Credit Exhaustion；

Update Delay；

长期等待，

就继续分析：

谁在等谁。

第六步，固定FIO条件。

没有完全一致的Workload，

所有性能数字都没有比较价值。

第七步，再判断到底改哪里。

可能是：

SSD Firmware；

Controller Architecture；

PHY；

PCB；

Switch Configuration；

Cable；

Adapter；

System Topology。

不要第一步就认定某一家有问题。

写在最后：Gen6验证真正的分水岭，不是“能不能跑到64GT/s”

PCIe Gen4、Gen5时代，我们已经越来越习惯问：

“Link起来了吗？”

到了Gen6，这个问题远远不够了。

PCIe 6.0已经进入：

64 GT/s；

PAM4；

FLIT；

FEC；

CRC + Replay

的新体系。

同时，真实服务器拓扑也越来越复杂：

CPU；

Switch；

Retimer；

Cable；

Backplane；

JBOF；

SSD；

CXL Memory Device。

一块设备如果只在：

CPU直连

环境里通过测试，

并不能代表它已经真正准备好进入数据中心。

真正成熟的Gen6验证应该继续问：

经过Switch以后，性能有没有变化？

Credit有没有被耗尽？

有没有异常Replay？

换成不同Host和Switch还能不能稳定工作？

进入8盘JBOF以后还能不能跑？

连续Power Cycle以后会不会掉盘？

CXL x8/x16以后，这套环境还能不能继续复用？

这也是这次技术交流最值得留下来的一个结论：

PCIe Gen6测试的目标，不是证明“链路通了”，而是证明设备进入真实系统拓扑以后，链路、协议、流控、性能和异常恢复依然全部正常。

真正把这些问题一个个找出来，

才叫：

Validation。

希望获得更多关于PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试技术和产品，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。