一个让我在客户现场熬到凌晨三点的故障
去年秋天，有个做运动控制设备的团队找到我，说他们的机器在实验室跑得好好的，一到客户产线上就随机出现“动作滞后”——操作手柄发出指令后，执行机构要等半秒甚至更久才响应，有时候干脆就像丢帧一样彻底没反应。
他们一开始怀疑是无线干扰，换了信道、加了屏蔽、甚至把天线挪到机柜外面，没用。又怀疑是主控算力不够，换了更高主频的处理器，还是没用。最后怀疑是执行机构本身的问题，换了另一批次的驱动器，依然如故。
我到现场之后，先让他们复现故障。操作员正常操作，我盯着总线分析仪看。大概每七八次操作就会出现一次延迟，延迟时间从几百毫秒到一秒多不等。但奇怪的是，所有报文都在总线上出现过，没有丢失，只是有些报文来得特别晚。
那天晚上我让他们把总线负载率实时打印出来。正常操作时负载率在45%左右波动，一旦操作员快速连续动作，负载率瞬间冲到80%以上，然后就看到低优先级的那几帧报文被压后了几百毫秒。问题根源找到了：不是丢帧，是延迟累积。
这件事让我意识到，很多工程师对总线负载率的理解停留在“不超过70%就安全”这种粗放经验上，却忽略了负载率对低优先级报文延迟的累积效应。这种累积不是线性的，而是会在某个临界点之后急剧恶化。
延迟累积到底是怎么发生的
要理解这个问题，得先抛开“负载率”这个笼统指标，去看总线上每一帧报文实际经历的东西。
假设总线上有高优先级报文H和低优先级报文L。当总线空闲时，L发出请求后可以立即获得总线控制权，延迟就是帧本身的传输时间。但当总线繁忙时，L发出请求后必须等待总线空闲，而且还要和其他同样等待的报文竞争。
这里有个容易被忽略的机
