Nico
Depending on the role of the particular system and or which company I
was working for at the time I've need one the other or both.
In my current role in the broadcast industry precision with
predictable latency is more important for most of my systems.
That said when I worked in the financial industry it changed based on
what part of the industy I was working for.
The stock exchanges I've worked for cared about precision because it
was more important to them to make sure every one had the same latency
and our logging was accurate for audit purposes.
When I used to work for a managed systems vender for hedge funds they
were all about low latency because the faster they got data in and out
of the exchanges often determined if they had an edge over their
competitors or not. quite literally an extra millisecond could cost
them millions of dollars a second due to the nature of high frequency
trading.

Generally I don't think of real time kernels when I am thinking about
low latency because oftent they increase the latency when dealing with
multiple operations. however the reverse can true if you only have a
box doing one specific task only but that rarely is the case.

By the way one of those stock exchanges is where the VMware engineers
told us never to use their product in production. In fact we had huge
problems with VMware in our development environments because some of
our applications would actually detect the clock instability in the
VMware clocks and would shut themselves down rather than have
inaccurate audit logs. as a result we found we had trouble even using
it in our development environments.

By the way Red hat only told me recently about guaranteeing the
microsecond precision of the clocks in KVM on RHEV and said they have
been doing it in financial for over a year. there are conditions
though such as you need to turn off support for overbooking the CPU
cores. last I checked VMware still says do not use their product
anywhere where you need millisecond accurate clocks.

Further more I dont know about that statement "Anyways, KVM will not
handle latency any better than Vmware." the article you pointed out
talks about VCPU's going in and out of halted states, which is normal
and completely expected in VMware because they always assume you are
going to overbook your CPU cores. there is a slight difference when
you talk about KVM in paravirtualized mode with overbooking disabled
it directly maps the CPU cores the the VM so as long as you don't have
power management enabled the CPU's are always operating at full speed
further more you can directly map PCIe bus address to the VM
(essentially assigning a card on your bus directly to the VM to be
completely managed by its kernel) to reduce latency in other ways to
hardware if you need too.

On Sun, Aug 24, 2014 at 2:02 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Sun, Aug 24, 2014 at 12:57 PM, John Lauro
> <[log in to unmask]> wrote:
>> Why spread FUD about Vmware.  Anyways, to hear what they say on the subject:
>> http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf
>>
>> Anyways, KVM will not handle latency any better than Vmware.
>>
>> ----- Original Message -----
>>> From: "Paul Robert Marino" <[log in to unmask]>
>>> To: "Nico Kadel-Garcia" <[log in to unmask]>
>>> Cc: "Brandon Vincent" <[log in to unmask]>, [log in to unmask], "[log in to unmask]"
>>> <[log in to unmask]>
>>> Sent: Sunday, August 24, 2014 12:26:17 PM
>>> Subject: Re: about realtime system
>>>
>>> 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
>
>
> I mentioned that I hope they were using real servers, not VM's. I'd
> had people try to run "real-time" systems in virtualization,
> specifically with VMware, and it wasn't workable for their needs.
>
> Also, "high precision" is not the same as "low latency", although both
> are often grouped together for "real-time" operations. I'm curious if
> Paul needs both.