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.