1
votes

I am working on a C++ application that can be qualified as a router. This application receives UDP packets on a given port (nearly 37 bytes each second) and must multicast them to another destinations within a 10 ms period. However, sometimes after packet reception, the retransmission exceeds the 10 ms limit and can reach the 100 ms. these off-limits delays are random. The application receives on the same Ethernet interface but on a different port other kind of packets (up to 200 packets of nearly 100 bytes each second). I am not sure that this later flow is disrupting the other one because these delay peaks are too scarce (2 packets among 10000 packets)

What can be the causes of these sporadic delays? And how to solve them?

P.S. My application is running on a Linux 2.6.18-238.el5PAE. Delays are measured between the reception of the packet and after the success of the transmission!

An image to be more clear : enter image description here

1
Check if your computer is doing something else at the time, that might preempt your software. Or check if there is a lot of network activity at the same time.Some programmer dude
You need to run your software with a very high priority and you have to carefully design to avoid problems like priority inversion. The problem could be anything not done correctly.David Schwartz
I have already tried to give high priority to emission thread,to socket, changing packet TOS, increasing network buffers without any success. In fact, I'm suspecting the kernel not making ready the socket on time.SlimShady

1 Answers

2
votes

10ms is a tough deadline for a non-realtime OS.

  • Assign your process to one of the realtime scheduling policies, e.g. SCHED_RR or SCHED_FIFO (some reading). It can be done in the code via sched_setscheduler() or from command line via chrt. Adjust the priority as well, while you're at it.

  • Make sure your code doesn't consume CPU more than it has to, or it will affect entire system performance.

  • You may also need RT_PREEMPT patch.

Overall, the task of generating Ethernet traffic to schedule on Linux is not an easy one. E.g. see BRUTE, a high-performance traffic generator; maybe you'll find something useful in its code or in the research paper.