一、PFC 产生原因

负责集群运维的同学可能都遇到过 PFC 现象，那么 PFC 到底是啥？产生原因是什么？这篇文章提供了一些分析。

首先，参考官网文档的说法：PFC（Priority-based Flow Control）的含义是基于优先级的流量控制，它是目前应用最广泛的能够有效避免丢包的流量控制技术，是智能无损网络的基础。使能了 PFC 功能的队列，我们称之为无损队列。当下游设备的无损队列发生拥塞时，下游设备会通知上游设备会停止发送该队列的流量，从而实现零丢包传输。我们来通过一个例子来理解一下。如下图所示，图中画出了一个昇腾集群中的部分 AI 服务器和交换机（switch），交换机的作用是实现不同服务器之间的通信（大多是在分布式训练任务中）。比如说 server 1、server 2 和 server 3 可以通过 switch 1 进行通信，server 2 和 server 3 可以通过 switch 2 进行通信。每个 switch 的收、发带宽都是固定的，而且都有一定的缓存空间。为啥需要缓存呢？因为有可能多个 server 同时发送流量过来，但是这些流量之和超过了 switch 的带宽，所以需要先放行部分流量，然后缓存剩下的。而且为了防止缓存超载，要设置一个水线，缓存超过这个水线，就会报警了，也就会触发下面所说的 PFC 现象了。

现在假设 switch 1 的入口带宽为 1.5M，缓存空间为 1.5M，缓存水线为 1M。假如某一时刻，server 1、server 2 同时向 switch 1 发送数据，server 1 的数据大小为 1.3M，server 2 发送的数据大小为 1.2M，那么 switch 1 可以让 server 1 或者 server 2 的数据先通过（例如 server 1 先过），然后缓存另一个。由于缓存的数据大小超过了 switch 1 的水线，所以此时 switch 1 会向 server 2 发送一个反压信号，告诉 server 2 不要再发数据来啦！但是当 switch 1 的缓存数据低于水线之后，它又会给 server 2 发个消息说：我 OK 啦，可以发消息啦！

所以说，反压信号包含 2 类，一类是 stop，一类是 continue。

同理，服务器侧的 NPU 也会有 PFC 信号，因为 NPU 可能会同时接收多个 switch 发送过来的消息。

二、PFC 原因排查

出现 PFC 现象后，会有两种结果，一种是对集群的性能产生了影响，甚至导致集群不可用；还有一种情况就是对性能没有影响。

我们先讨论后一种情况，这种情况很可能是并行通信过程中常见的“多打一”场景，也就是服务器同时收到多个交换机发送的数据或者交换机同时收到多个服务器发送过来的消息。我们可以利用 mindstudio insight 来判断是否存在这种情况，下面通过一个例子来解释。

假如我们现在有一份多机多卡的 profiling，我们使用 mindstudio insight 把它加载进来，然后查看 timeline 和“通信”子界面的通信算子的时序，从而判断是否有“多打一”的情况。

2.1 服务器侧 NPU 可能出现 PFC 的场景

NPU 侧出现“多打一”，是因为同时收到了多个交换机发送过来的数据，所以我们可以观察每个卡的 HCCL timeline，看看是否有多个跨机通信域的通信算子同时执行。注意，这里强调“跨机”是因为只有跨机的通信才会用到交换机。跨机通信域一般包括 pipeline 并行、数据并行等，具体哪些通信域是跨机的，还需要根据实际的并行配置进行判断。

如上图所示，红框截图就是 1 号卡的通信域的算子执行时序，每个卡有多个通信域，因为这个卡可能同时参与了多种并行，蓝框的每个 plane 反馈的也是通信行为，只是它反馈的是 task 粒度，Group xx communication 反馈的是算子粒度。我们点击绿框中的标记就可以把这一行置顶。所以我们可以把 1 号卡的多个跨机通信域的算子执行序置顶，这样就可以看到哪些算子存在并发行为。那么有同学问了，我怎么知道哪些 communication group 是跨机通信域呢？1，版本开发的同学正在做一个需求，就是显示每个 communication group 对应哪些卡，这样我们就可以知道是不是跨机通信域了，比如说 4 机 32 卡的集群，[0, 8, 16, 24]组成的一个通信域就是跨机的（0 号卡属于 1 号服务器，8 卡属于 2 号服务器，16 卡属于 3 号服务器，24 卡属于 4 号服务器）；2，在这个需求做出来之前，我们可以通过分析这个 group 里面的通信算子类别判断它对应的是什么通信域：）。

上图是把 1 号卡的不同通信域算子执行序置顶后的结果，我们可以把时间轴拉开，看看不同的跨机通信域的通信算子（reveice 过程）是否存在并发状态，如果有，那么很可能会导致服务器侧出现 PFC 现象！

2.2 交换机可能出现 PFC 的场景

交换机出现“多打一”，是因为同时有多个跨机通信行为使用了同一个交换机进行数据交换。有 2 种情况会导致这种行为发生，一种是上面举例的[0, 8, 16, 24]组成的通信域中，多个卡同时向同一个交换机发送数据；另一种是多个跨机通信域中的多个卡，同时向同一个交换机发送数据。

对于前一种情况，我们可以如下打开 mindstudio 的通信界面，选择一个跨机通信域（下面的示例不一定是跨机通信域，只是为了演示），然后查看有没有多个卡存在并发通信算子（send 过程）。

对于后一种情况，我们需要再次使用 timeline，在已知哪些卡对应于同一个交换机的情况下（怎么知道这个信息？后续再补充，知道的朋友可以在评论区补充），把这些卡的 communication group 都置顶进行比较分析，观察是否有通信算子（send 过程）的并发行为。

好的，到这里告一段落，主要介绍了如何使用 mindstudio insight 分析可能产生 PFC 的场景。

大家有没有遇到过 PFC 现象呢？欢迎留言讨论！