3

请帮忙！我有一个需要尽可能接近实时处理的应用程序，我一直遇到 TCP 和 UDP 的这种不寻常的延迟问题。延迟就像发条一样发生，并且总是相同的时间长度（主要是 15 到 16 毫秒）。它发生在传输到任何机器（前夕本地）和任何网络（我们有两个）上。

快速解决问题：

我总是在 C++ 中使用 winsock，在 VS 2008 Pro 中编译，但我已经编写了几个程序来使用 TCP 和 UDP 以各种方式发送和接收。我总是使用以各种语言（MATLAB、C#、C++）编写的中间程序（在本地或远程运行）将信息从一个程序转发到另一个程序。两个 Winsock 程序都在同一台机器上运行，因此它们显示来自同一时钟的 Tx 和 Rx 的时间戳。我一直看到一种模式出现，其中将传输一串数据包，然后在下一次突发之前有大约 15 到 16 毫秒的延迟，尽管没有编程延迟。有时每个数据包之间可能是 15 到 16 毫秒，而不是一连串的数据包。其他时候（很少）我会有不同长度的延迟，比如~47 ms。

我怀疑 winsock 或 NIC 在每次传输之前都在缓冲数据包，但我没有找到任何证据。我有一个千兆连接到一个获得不同级别流量的网络，但是当我在一个集群上运行中间程序时也遇到同样的事情，该集群有一个没有流量的专用网络（至少来自用户）和一个 2 千兆连接。当使用发送和接收程序在本地运行中间程序时，我什至会遇到这种延迟。

4

5 回答 5

5

今天早上我在用 Java 重写服务器时发现了这个问题。我的 Windows 系统时钟的分辨率在 15 到 16 毫秒之间。这意味着显示与其传输时间相同的毫秒的每个数据包实际上是以 16 毫秒的间隔以不同的毫秒发送的，但我的时间戳仅每 15 到 16 毫秒递增一次，因此它们看起来相同。

我来这里是为了回答我的问题，我看到了关于提高我的程序优先级的回复。所以我启动了所有三个程序，进入任务管理器，将所有三个程序提高到“实时”优先级（没有其他进程处于）并运行它们。我得到了相同的 15 到 16 毫秒的间隔。

不过感谢您的回复。

于 2009-10-28T14:21:23.270 回答
2

总是涉及缓冲，并且它在硬件/驱动程序/操作系统等之间有所不同。数据包调度程序也起着重要作用。

如果您想要“硬实时”保证，您可能应该远离 Windows...

于 2009-10-27T14:55:38.933 回答
0

您可能看到的是调度程序延迟 - 您的应用程序正在等待其他进程完成它们的时间片并放弃 CPU。多处理器 Windows 上的标准时间片从 15 毫秒到 180 毫秒。

您可以尝试提高应用程序/线程的优先级。

于 2009-10-27T23:51:28.733 回答
0

哦，是的，我知道你的意思。Windows 及其缓冲区...尝试调整发送方的 SO_SNDBUF 和接收方的 SO_RCVBUF 的值。此外，检查涉及的网络硬件（路由器、交换机、媒体网关）——尽可能多地消除机器之间的问题以避免延迟。

于 2012-12-28T06:56:40.213 回答
0

我遇到同样的问题。但在我的情况下，我GetTickCount()用来获取当前系统时间，不幸的是它总是有 15-16ms 的分辨率。当我使用QueryPerformanceCounter而不是GetTickCount()，一切都很好。事实上，TCP socket 接收数据是均匀的，不是 15ms 处理一次。

于 2019-10-29T03:44:01.103 回答