login
Search
I am wondering if there is anything else that we can do other than applying PREEMPT_RT patch to the Linux Kernel to get real time support? Does having real-time driver (say a network card) help in improving the performance? Or perhaps there is nothing like Real-time driver.....I apologize for my lack of understanding (if any)....
Be careful with language here
You're in a dangerous zone where the computer science terms and common-sense terms don't quite overlap.
Real-time drivers can indeed improve the latency bounds of the system, at a throughput (and sometimes a minimum latency) cost - in the case of Linux, however, most drivers are as tight as possible, and it's the core code (e.g. the networking stack, not the NIC drivers) that needs work.
Given that you're being non-specific ("performance" as against throughput or latency), I suspect you've been thinking that the RT kernel options improve everything; if they did, they wouldn't be options. What they do is reduce the maximum latency of any kernel operation, at the expense of slight reductions in throughput here and there; they're not worried about minimum latency, as it's possible (given a fixed maximum latency) to compensate for returns that are too quick.
It's been a long time since I benchmarked the RT kernel, but when I last did, using gigabit ethernet and a custom app, I measured peak latencies dropping from 600 milliseconds to around 50 milliseconds, but throughput dropped from 400 megabits/second to 300 megabits/second. Worth thinking about, anyway.
Sorry for the wrong language
First of all thanks for the detailed reply and sorry for the "wrong" language. What I meant was: "does real-time driver further improve (minimize) the latency of a given RT kernel (PREEMPT_RT patch)". I do understand (and thanks for reminding me again) that minimize latency comes at the cost of the performance.
If I understand your reply correctly it seems that most of the drivers available in the kernel don't need to be modified to get further minimize latency from the RT kernel. If at all there has to be done anything to further improve the latency we have to modify the sub-system i.e. in this case the networking stack - is that correct?
You made me curious with one of your sentences - How did you measured/benchmarked the decrease in performance with the RT kernel?
network latency
it sounds you want to lower the latency of network transfers? which type of traffic do you have (using the machine as a router that has to forward packets with minimum latency or an application on the machine)? which protocol do you use, e.g. does it retransmit like tcp in case of packet drop or errors or do you use udp and can ignore missing data? is the latency really in the networking stack or in the network and protocols? which type of interconnect do you have, i.e. which bandwidth and maximum packet size? are there any routers/switches/hubs involved? does the medium have any latency guarantees? do you use quality of service tags and traffic shaping or a more advanced type of priorization?
how to measure decrease of performance? Anonymous obviously just run the same application on each of the kernels and measured the time and/or monitored the interface data rates. and measured the latencies, which in the easiest case is something like ping, but may involve interface timestamps or similar.