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.