3 ms·

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

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.

zwieback 7y ago
I interpreted the Linux thing as just making the Linux host a better analysis tool, the main focus was the embedded system side. I would probably use Wireshark to find the packet timing, who knows what happens in something as complex an OS as Linux. You can also use something like Wireshark to extract debug payloads like ISR or DMA timing on the embedded system although admittedly a script on the LInux side is easier.
abondarev 7y ago
I hope too that most developers already know that they need to use real-time schedulers for real-time work. But I'm not sure that you understood to the end the problem and solution. chrt --rr 99 ./client It's only the test machine to make sure that de0_nano_fpga part work correctly. Linux on de0_nano_fpga, of cause, run with real-time features. The times (Min: 0.74ms) are for Linux with real-time schedulers.

zwieback 7y ago

I interpreted the Linux thing as just making the Linux host a better analysis tool, the main focus was the embedded system side. I would probably use Wireshark to find the packet timing, who knows what happens in something as complex an OS as Linux. You can also use something like Wireshark to extract debug payloads like ISR or DMA timing on the embedded system although admittedly a script on the LInux side is easier.

abondarev 7y ago

I hope too that most developers already know that they need to use real-time schedulers for real-time work. But I'm not sure that you understood to the end the problem and solution. chrt --rr 99 ./client It's only the test machine to make sure that de0_nano_fpga part work correctly. Linux on de0_nano_fpga, of cause, run with real-time features. The times (Min: 0.74ms) are for Linux with real-time schedulers.