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 <[log in to unmask]> 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" <[log in to unmask]>
>> To: "Nico Kadel-Garcia" <[log in to unmask]>
>> Cc: "John Lauro" <[log in to unmask]>, "Brandon Vincent" <[log in to unmask]>, "Lee Kin"
>> <[log in to unmask]>, "[log in to unmask]" <[log in to unmask]>
>> 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.