I'm glad he solved his problem, and I guess it's good to post "I solved this problem" information.

But this seems painfully obvious. TL;DR: "I had a demanding real-time requirement for a Linux process, I fixed it by using the Linux real-time scheduler for my real-time process."

Let's look at this in more detail. He's trying to implement time-critical functions with Linux and has a demanding real-time requirement ("Maximum acceptable latency is 0.1ms while basic Linux solution could only provide 0.5ms."). He's even struggling getting this latency with an RTOS (!). He's not getting the real-time latency he needs by using the default Linux settings. He also can't get it by setting the "nice" value, but the "nice" value isn't relevant for real-time processes... which makes it clear that he's trying to get real-time performance without using the real-time schedulers.

His solution:

    chrt --rr 99 ./client

That asks Linux to using the SCHED_RR (Round-robin scheduling) scheduler, one of its real-time policies, instead of the default (non-real-time) scheduler.

In short: If you're doing real-time work, you need to use a real-time scheduler for it.

Technically this doesn't completely solve his problem; if he was serious about 0.1 msec, SCHED_RR isn't doing it as shown by the posted bar chart. But he seemed happy enough with it, so perhaps his requirements are really more probabilistic ("X% of the time, UDP must be delivered in 0.1 msec").

Again, I'm glad he solved his problem, but I hope most developers already know that they need to use real-time schedulers for real-time work.