The stock exchange could remove most of the problem, meaning high
frequency trades, by placing a purely random 0 to 1 second latency
on all incoming data and all outgoing data. The high frequency trading
reads to me as just another means of skimming now that they're not
allowed to round down fractional pennies and pocket the change. It's
time to give mere mortals some practical access to the exchanges. And
this interest in microsecond clocks would simply vanish from the
exchanges.

On a different point, the word I can find is that the free version of
VMWare does not support this "high latency sensitivity" setting.

{o.o}   Joanne, Just sayin'

On 2014-08-24 13:42, Paul Robert Marino wrote:
> 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.
>