让 Nexus 3132Q-X 的风扇安静下来

家里的 Cisco Nexus 3132Q-X 一直有个问题：风扇太吵。网络功能用得好好的，可放在家里，默认的最低转速还是有点难受。

这次和 Codex 一起沿着温控逻辑查下去，终于让它安静了下来。最低控制档从 50 改成 20，四个风扇模组、八个转子的实际转速都降了下来。第一次生效后，我去听了一下，明显安静了。

改的是运行中的数据

测试设备是 Nexus 3132Q-X，NX-OS 版本为 7.0(3)I7(9)，使用四个 NXA-FAN-30CFM 双转子风扇模组。

找到的办法是在运行中的 PFM 进程里修改风扇曲线数据，不改固件镜像、磁盘上的可执行文件，也不改机器指令。原来的最低档是 50，改成 20 后，高温时的 70、99 档，以及原有的温度阈值、滞回和升降档逻辑仍然保留。

这里的 20、50 是设备的控制值，不是线性的转速百分比。实际测到的变化是：

一个有意思的细节是，只把内存里的“当前档位”写成 20，还不一定能让风扇真的慢下来。缓存状态如果让程序以为目标档位已经生效，就不会通知底层驱动。补丁需要让原有逻辑产生一次真实的降档通知，最后再检查八个转子的 RPM，而不是只看显示出来的档位。

用 Scheduler 定期检查

运行时修改有一个特点：交换机重启，或者 PFM 进程重启，都会重新加载原来的数据，最低档回到 50。

因此，我用 NX-OS 自带的 Scheduler 每分钟检查一次。脚本核对固件和运行状态后，在条件允许时重新应用补丁；已经处于高温 70、99 档时，不会强行拉回 20。任务配置已经保存，脚本放在 bootflash 上，不过完整重启后的恢复流程还没有实测。

恢复也做了验证：先用持久禁用标记阻止 Scheduler 再次应用补丁，然后恢复原最低档 50，并确认实际 RPM 上升。重新启用后，风扇又能回到 20。

两小时温度测试

风扇慢下来之后，接下来就是看温度。

最初的计划是观察一小时，每 30 秒采样，每五分钟汇报一次。如果最后 20 分钟温度仍在上升，就再观察一小时；如果两小时后还没有平衡，再考虑把最低档提高到 30。

第一小时末还有轻微升温，所以继续测了第二小时。两段观察共留下 242 个有效样本，没有采样错误，八个转子一直保持在 20 档。最后 20 分钟，各温度传感器的窗口峰值不再上升，没有用到 30 档。

图里的横轴是相对观察时间，保留了两次采样之间约 34 秒的真实间隔。转速图分开显示每个模组的两个转子，各图纵轴范围不同。

后续抽查，ASIC 仍在 59°C 左右，四个风扇模组状态正常。这些是抽查结果，不代表期间一直在连续监控。

功率读数的小插曲

我还想看看降速能省多少电，于是临时把最低档恢复到 50，确认转速真的升起来后保持五分钟，再恢复 20。

降温效果很明显：ASIC 从 60°C 降到了 42°C。测试时只有一个电源处于工作状态，下面是当时负载和环境下的整机读数。电源内部报告的输入功率差得很小：

乍一看只差 1.31 W，好像八个转子降速也没省多少。再检查原始数据，17 次输入电流读数全部是 0.38 A，报告的功率变化则与输入电压变化一致；恢复 20 后，读数也没有立刻下降。

所以，这次测到的是整机内部遥测值，还不能据此说风扇只省了 1 W 多。要分清实际功率差，仍需要用外部功率计做对照。五分钟的测试也只是短时对照，没有拿它判断长期热平衡。眼下最明确的收获是噪声明显降低。

代码和测试记录

代码已经公开：

Leonccaa/nexus-fan-runtime

仓库里有运行时补丁、Scheduler 部署与恢复方法、英文测试说明、脱敏后的两小时 CSV 和图表。Codex 完成了大部分代码、固件分析和自动化验证，我负责确定目标，并在设备实际运行时确认噪声变化。

目前补丁只接受这次验证过的固件指纹。类似 Nexus 设备也许可以沿着同样的方向研究，但具体进程、数据位置和驱动行为需要重新核对，不能直接照搬偏移量。高温升档做了原始指令的离线验证，还没有在硬件上刻意触发。

现在先让这台交换机保持在最低 20 档。它终于安静了，暂时也不用为了噪声去换风扇。