Wow I don't know how VMware got mentioned in this string but VMware is not capable of real time operation and if you ask the senior engineers at VMware they will tell you they don't want you even trying it on their product because they know it wont work. The reason is VMware plays games with the clock on the VM so the clocks can never be 100% accurate. It should be possible to do real time in KVM assuming you don't overbook your CPU Cores or RAM. Apparently Red Hat has been doing VM's with microsecond accurate clocks with PTP running on the visualization hosts so realtime should be possible as well. The big thing to keep in mind with real time kernels is it makes the system extremely slow. In essence you are giving up speed for precision. This level of precision is rarely needed these days because the kernel has evolved to the point where the scheduler and preemption has been tuned over the years well enough that its good enough for most needs on a properly tuned box. the real time Linux kernels were a very big deal back in the late 90s before preemption was added to the kernel and in the 2.4 and early 2.6 series Kernels preemption was still new and wasn't as well tuned as it is now so it still had a lot of uses but all of this has changed now. What I would suggest if you really need real time is to use small or embeded systems network booted and running off of ram disks to do all of the real time work and do most of the heavy lifting in on standard systems. Here is my summary In most cases kick starting a system with the nobase option and very precisely limiting what you install on the system in combination with good hardware will usually deliver the accuracy you need for most uses. The notable exceptions is where you cant deal with latency due to buffers such as safety mechanisms for high speed systems, or if you are doing high speed (microsecond) precision data sampling over long periods of time. I think the article mentioned before on ni.com has a bad explanation of something it mentions to use it for reliability over a long period of time which I think very poor phrasing. what they are talking about is reliable precision over a long period of time. That said I've run hundreds of mission critical systems many accurate to within 5 milliseconds on the standard kernel with proper tuning and a stripped down OS install for nearly a decade and Ive never had an issue. On Sun, Aug 24, 2014 at 7:40 AM, Nico Kadel-Garcia <[log in to unmask]> wrote: > On Sat, Aug 23, 2014 at 11:20 PM, Brandon Vincent > <[log in to unmask]> wrote: >> On Fri, Aug 22, 2014 at 9:41 AM, <[log in to unmask]> wrote: >>> Does it really make difference in timing control comparing to non-realtime >>> kernel? Thanks. >> >> Whether or not you need a RTOS depends on your specific needs. Since >> you're working with LabVIEW, I would check out their white paper on >> the subject. >> >> http://www.ni.com/white-paper/14238/en/ > > I assume you're running real hardware, instead of virtual systems? > I've seen people try to run "real-time" systems in virtuaalized, > CentOS based VMware systems, and the results for extremely low latency > operations were not encouraging. I also spent a lot of time with that > with CentOS 5 making sure the hosted partitions were 4096 byte block > aligned, which made a *big* difference with NetApp backend disk image > storage. > >>> I don't have NI's realtime system but I am looking for a free linux OS which >>> supports realtime kernel. So I wonder does anyone have experience in >>> this on scientific linux? Does it support realtime kernel? >> >> NI Linux Real-Time is based off of the PREEMPT_RT patch set which you >> can find on the kernel.org Wiki. >> >> https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch >> >> I've never compiled an EL kernel with the patch, but there is no >> reason why it should not be possible. >> >> Brandon Vincent > > If you go this route, do look into creating kernel RPM's with the > "mock" toolkit and with patches applied as part of the SRPM. It's > extra work to start with, but lets you manage the kernels and report > dependencies more effectively.