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 回答