Hello,

I have two applications that exchange UDP datagrams. For the most part, the receiving application is able to get data via the recvfrom() call without any delay. Occasionally, I see that although the sender (using write() into socket fd) sends the data, there is a considerable amount of delay (~100 msec) before the receiver sees the data (Polling via recvfrom()).

I would like to get few pointers/hints so I can debug this.

Questions:

1. I noticed that /proc/net/udp shows a snapshot of the sockets with the rx/tx queues. Is the data flow below accurate?

sender user space buffer -> Kernel UDP tx buffer -> Kernel UDP rx buffer -> receiver user space buffer.

I'd like to know if I can debug the latency issue just by relying on monitoring the rx/tx queues in /proc/net/udp. Is there any other way I can do this?

2. I have verified that the sender and receiver threads are not starved of CPU time. Given this, is there anything else that is likely to cause the data to not show up on the receiver socket?

Any hints/directions you can give will be helpful. Thanks for reading.

Hi premp,

I'm observing exactly the same problem, in my case, I'm using sendto(), poll() and recv() on 8 sockets to exchange request/reply every 1 milliseconds. Randomly I'm observing a reply being delayed 100 milliseconds only on one socket, all other sockets are receiving reply normally meanwhile. I did also reproduce the problem using only one socket.

Additional tests shown that sending a request and receiving the reply pushes the old reply out of the socket, but the new reply is not received and again waits for the next reply to come in for a period of 100 milliseconds then the situation goes back to normal on that socket.

Do you do look-back on same machine?

No we are exchanging messages with 8 external IP devices on the same Ethernet bus.

Basically, Linux OS isn't real time OS. So you can't expect that Linux always response as soon as possible, most time is fine.

There is something that blocks the reception of the buffer in the socket that is pushed by the next reply, I do not believe this has nothing to do with the real-time nature of Linux.