Windows 网络中的可变延迟
Variable latency in Windows networking
我有一个每 24 毫秒发送一次 UDP 数据包的 PLC。 "Simultaneously"（即在几十或最多数百微秒的时间内），同一个 PLC 触发相机拍摄图像。有一个 Windows 8.1 系统可以接收图像和 UDP 数据包，还有一个应用程序 运行 它应该能够将每个图像与来自 PLC 的 UDP 数据包相匹配。
大多数时候，就 Windows 应用程序而言，两个事件之间存在合理固定的延迟 - 20 毫秒 +/- 5 毫秒。但有时延迟会上升，而且永远不会真正下降。最终它超出了我所拥有的匹配缓冲区的范围，并且这两个系统会自行重置，这总是以 "normal" 级别的延迟开始。
令我困惑的是这种可变延迟的可变性 - 有时它会整天保持在 20 毫秒 +/- 5 毫秒，但在其他日子里它会定期快速增加，而且我们的系统经常令人不安地自我重置。
这里可能发生了什么？可以做些什么来修复它？ Windows 可能是延迟的来源，还是 PLC 系统？
我 99% 怀疑 Windows，因为 PLC 是为实时响应而设计的，而 Windows 不是。 Windows 这听起来 "normal" 吗？如果是这样，即使有其他进程争用网络 and/or 其他资源，为什么 Windows 似乎从未赶上 - 发生争用时延迟增加，但 return争用停止后恢复到正常延迟水平？
仅供参考：Windows 应用程序调用 SetPriorityClass( GetCurrentProcess(), REALTIME_PRIORITY_CLASS ) 并且每个关键线程都以 AfxBeginThread( SomeThread, pSomeParam, THREAD_PRIORITY_TIME_CRITICAL ) 启动。系统上的 else 运行 尽可能少，应用程序仅使用可用四核处理器的大约 5%（具有超线程，因此 8 个有效处理器）。虽然我正在考虑SetThreadAffinityMask()，但没有用。
所以，你有两个设备，PLC 和摄像头，它们使用 UDP 向同一台 PC 发送数据。
我 90% 怀疑网络。
要么只是 switch/router 中的缓冲/整形机制（顺便说一句，我希望你的设置是独立的，即你没有将硬件插入繁忙的公司网络），要么是网络堆栈设备，或者 PLC 中的一些自定义重传机制。 IP 和以太网协议从来都不是为了保证低延迟。
要验证，请使用Wireshark查看网络流量。
为获得最佳实验效果，您可以使用另一台配备三块网卡的电脑。
将您的三个设备（windows 客户端、PLC、相机）插入该 PC，然后配置 network bridge between the 3 cards。这样，第二台 PC 将充当以太网交换机，您将能够使用 Wireshark 捕获通过它的所有网络流量。
答案原来是多种因素之间的复杂相互作用，其中大多数因素不会传达任何对他人有用的信息...除了 "just because it seems to have been running fine for 12 months doesn't give you licence to assume everything was actually OK."
的例子
问题的关键在于 PLC 是来自 Beckhoff 的设备，其上连接了多个 I/O 模块。事实证明，附加的这些模块越多，PLC 传输 UDP 数据包的能力就越弱，尽管有足够的处理器时间和可用的网络带宽。看起来像是我们尚未解决的某种资源争用问题 - 我们只是选择升级到功能更强大的 PLC 设备。该设备仍然存在同样的问题，但如果您尝试大约每 10 毫秒而不是 24 毫秒传输一次，就会出现问题。
问题的出现是因为我们的 PLC 应用程序在其 UDP 传输能力的阈值上运行。 PLC 必须逐步通过状态机中的状态才能进行传输。使用 2 毫秒的 PLC 周期，它可以通过我们附加的 I/O 模块的状态机中最快的状态是每 22 毫秒。
最后，最初被认为是 PLC 启动时微不足道且无关的变化将其推向了边缘，使其偶尔无法跟上正常的 24 毫秒传输周期。所以它会逐渐落后，表现出越来越多的延迟。
我接受@Soonts 的回答，因为对一些 Wireshark 捕获的仔细分析是解开正在发生的事情的关键。
我有一个每 24 毫秒发送一次 UDP 数据包的 PLC。 "Simultaneously"（即在几十或最多数百微秒的时间内），同一个 PLC 触发相机拍摄图像。有一个 Windows 8.1 系统可以接收图像和 UDP 数据包，还有一个应用程序 运行 它应该能够将每个图像与来自 PLC 的 UDP 数据包相匹配。
大多数时候，就 Windows 应用程序而言，两个事件之间存在合理固定的延迟 - 20 毫秒 +/- 5 毫秒。但有时延迟会上升，而且永远不会真正下降。最终它超出了我所拥有的匹配缓冲区的范围，并且这两个系统会自行重置，这总是以 "normal" 级别的延迟开始。
令我困惑的是这种可变延迟的可变性 - 有时它会整天保持在 20 毫秒 +/- 5 毫秒，但在其他日子里它会定期快速增加，而且我们的系统经常令人不安地自我重置。
这里可能发生了什么？可以做些什么来修复它？ Windows 可能是延迟的来源，还是 PLC 系统？
我 99% 怀疑 Windows，因为 PLC 是为实时响应而设计的，而 Windows 不是。 Windows 这听起来 "normal" 吗？如果是这样，即使有其他进程争用网络 and/or 其他资源，为什么 Windows 似乎从未赶上 - 发生争用时延迟增加，但 return争用停止后恢复到正常延迟水平？
仅供参考：Windows 应用程序调用 SetPriorityClass( GetCurrentProcess(), REALTIME_PRIORITY_CLASS ) 并且每个关键线程都以 AfxBeginThread( SomeThread, pSomeParam, THREAD_PRIORITY_TIME_CRITICAL ) 启动。系统上的 else 运行 尽可能少，应用程序仅使用可用四核处理器的大约 5%（具有超线程，因此 8 个有效处理器）。虽然我正在考虑SetThreadAffinityMask()，但没有用。
所以，你有两个设备，PLC 和摄像头，它们使用 UDP 向同一台 PC 发送数据。
我 90% 怀疑网络。
要么只是 switch/router 中的缓冲/整形机制（顺便说一句，我希望你的设置是独立的，即你没有将硬件插入繁忙的公司网络），要么是网络堆栈设备，或者 PLC 中的一些自定义重传机制。 IP 和以太网协议从来都不是为了保证低延迟。
要验证，请使用Wireshark查看网络流量。
为获得最佳实验效果，您可以使用另一台配备三块网卡的电脑。
将您的三个设备（windows 客户端、PLC、相机）插入该 PC，然后配置 network bridge between the 3 cards。这样，第二台 PC 将充当以太网交换机，您将能够使用 Wireshark 捕获通过它的所有网络流量。
答案原来是多种因素之间的复杂相互作用，其中大多数因素不会传达任何对他人有用的信息...除了 "just because it seems to have been running fine for 12 months doesn't give you licence to assume everything was actually OK."
的例子问题的关键在于 PLC 是来自 Beckhoff 的设备，其上连接了多个 I/O 模块。事实证明，附加的这些模块越多，PLC 传输 UDP 数据包的能力就越弱，尽管有足够的处理器时间和可用的网络带宽。看起来像是我们尚未解决的某种资源争用问题 - 我们只是选择升级到功能更强大的 PLC 设备。该设备仍然存在同样的问题，但如果您尝试大约每 10 毫秒而不是 24 毫秒传输一次，就会出现问题。
问题的出现是因为我们的 PLC 应用程序在其 UDP 传输能力的阈值上运行。 PLC 必须逐步通过状态机中的状态才能进行传输。使用 2 毫秒的 PLC 周期，它可以通过我们附加的 I/O 模块的状态机中最快的状态是每 22 毫秒。
最后，最初被认为是 PLC 启动时微不足道且无关的变化将其推向了边缘，使其偶尔无法跟上正常的 24 毫秒传输周期。所以它会逐渐落后，表现出越来越多的延迟。
我接受@Soonts 的回答，因为对一些 Wireshark 捕获的仔细分析是解开正在发生的事情的关键。