John reread the first and third paragraph of my previous email. Trading firms care about low latency but never cared about the accuracy millisecond of the clocks. Sock exchanges on the other hand want predictable latency not necessarily low latency but absolutely require millisecond and if possible microsecond accurate clocks. The reason for this is trading funds are worried about getting quotes, bids, executions, etc. to the exchanges gateways as fast as possible; however the exchange has to be able to prove to both the member firms and the regulators that everyone is treated fairly once they put an order into the gateway.
While yes VMware says under very specific configurations with 3/4ths of their features disabled and special network cards which offload their virtual switch's work VMware can handle "low latency", but they still can not handle clocks accurate to the millisecond and certain cant handle it to the microsecond. Furthermore I find this article highly suspect because its talking about reducing the latency overhead in their visualization stack to the point where it becomes less noticeable not necessarily true low latency. This makes it acceptable for small hedge funds which have staff and equipment budget constraints, but not really good enough for the big boys if they are smart. I would advise you to be careful with VMwares "technical" marketing docs and blogs in this area because the sale people will tell you anything to get you to buy it, their high level engineers will actually tell you the truth if they know what you are using it for. In true real time and high precision situations their senior engineers will tell the sales department to wave you off of using their product if your employer is a big enough name for for the real senior engineers (not "sales engineers") to look at your design prior to sale. If you dive deep into that article it say's you need 1) very specific hardware support specifically network cards 2) you need to turn off vmotion and all of the other fault tolerance features 3) you need to have very specific features turned on 4) It makes strongly implied suggestion but doesn't state flat out that for best performance you need to align the number of cores you assign to the layout of the cache in your CPU so you don't get multiple VM's sharing CPU cache even if that means assigning more VCPUs than you need. 5) a separate physical network card for each VM 6) disable memory over committing (Same as KVM) 7) disable CPU over committing (Same as KVM) Even with that all of that you still do not have a 10 microsecond latency jitter in the network stack, and the accuracy of the clocks are still not guaranteed to the millisecond. In no place in that article or the blog is clock accuracy mentioned at all. All they are talking about is better response time latency not real precision. On Sun, Aug 24, 2014 at 3:46 PM, John Lauro <john.la...@covenanteyes.com> wrote: > The recommendation changed with 5.5. > http://blogs.vmware.com/performance/2013/09/deploying-extremely-latency-sensitive-applications-in-vmware-vsphere-5-5.html > > "... However, performance demands of latency-sensitive applications with very > low latency requirements such as distributed in-memory data management, stock > trading, and high-performance computing have long been thought to be > incompatible with virtualization. > vSphere 5.5 includes a new feature for setting latency sensitivity in order > to support virtual machines with strict latency requirements." > > > ----- Original Message ----- >> From: "Paul Robert Marino" <prmari...@gmail.com> >> To: "Nico Kadel-Garcia" <nka...@gmail.com> >> Cc: "John Lauro" <john.la...@covenanteyes.com>, "Brandon Vincent" >> <brandon.vinc...@asu.edu>, "Lee Kin" >> <llwa...@gmail.com>, "SCIENTIFIC-LINUX-USERS@FNAL.GOV" >> <scientific-linux-users@fnal.gov> >> Sent: Sunday, August 24, 2014 3:27:39 PM >> Subject: Re: about realtime system > ... >> 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.