PS. That last paragraph was intended to respond to John not Nico.

On Sun, Aug 24, 2014 at 3:27 PM, Paul Robert Marino <[log in to unmask]> wrote:
> 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.