Spurious packet reordering on UDP point-2-point connection

thorfdbg

Hi folks,

maybe someone has an idea about an oddity of UDP transport in the Linux kernel. I have here an application that transmits a stream of UDP packets at a rate of about 135 MByte/sec, connected directly (no routers, point to point) to a receiver. At this point, source and sink are single-threaded.

At the receiving end, I observe the following:

When I first start the receiver, then start the sender, everything is fine. Packets arrive in production order, and as there is nothing between the two machines but an optical fibre, packets arrive in order and I never see any form of packet loss or packet reordering.

However, if I first start the sender, and then start the receiver, the receiver sees all types of oddities, such as receiving packets out of order, or seeing some packets not at all. I would have assumed that this odd behaivour may show up initially as the kernel ring buffer (is there such a thing?) first needs to run dry of all the old packets received before, but instead, the problem persists for several minutes, though stabilizes at a while. As the application is some form of video-over-IP, this type of behaiviour is not acceptable except for a small number of frames.

Strangely enough, if I inspect the transport through wireshark, everything looks fine, and packets are buffered there in the expected and correct order, even if I first start the sender and then the receiver.

The current receiver is primitive - just a loop over recvfrom() - and an inspection of a transport-specific sequence number, so I can almost certainly exclude an implementation problem there.

So, what does wireshark so different than using recvfrom - or is there any other way to avoid reordering and reshuffling of UDP traffic within the kernel?

Thanks for any hints or advices,

Thomas