[time-nuts] Google NTP Servers and smearing leap seconds...

[Bob Paddock]

On Fri, Sep 16, 2011 at 2:36 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
> xaos at darksmile.net said:
>> You can forget Wall St. firms and Banks for starters.
>
>> They need sub-microsecond accurate timing as some instruments (Forex)   are
>> moving to <10 microsecond latency from order entry to order ack.
>
> 10 microsecond latency doesn't say anything about how accurate the time has
> to be.
>
> Does anybody have a good URL on the accuracy requirements of banks and/or
> stock markets?  I expect there are both legal and technical issues.  I'd like
> to understand them separately

There are some big names in Banking and Stocks behind the
 Advanced Message Queuing Protocol (AMQP):

http://www.amqp.org/confluence/display/AMQP/About+AMQP

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp

http://amqp.org/resources/financial-services

Actually Time Nut Grade measurements are not addressed at this level
to my knowledge.

      <p><b>Round Trip</b>: The term round trip refers to the
      process of a peer sending a command to its partner and
      receiving confirmation that the command is complete. Round
      trips are necessary for synchronization of world views,
      however, it is not necessary for a client to wait and do
      nothing while a round trip occurs or only deal with a single
      round trip at a time.</p>
    </li>

    <li>
      <p><b>Round Trip Time (RTT)</b>: The term RTT refers to the
      time taken to complete a round trip. This is described with
      the following formula:</p>
      <pre>
RTT = 2*latency_network + latency_processing
</pre>

      <p>Note that RTT at the execution layer differs from RTT at
      the network layer. At the network layer the processing
      latency is zero resulting in an RTT of twice the network
      latency. At the execution layer the processing time becomes
      significant if, for example, processing the command requires
      sending data to disk. This would be the case with durable
      messages and the RTT would then include the Broker's disk
      latency.</p>
    </li>

> but I won't be surprised if they are thoroughly
> tangled.

http://www.imatix.com/articles:whats-wrong-with-amqp

There is also the even more obscure 0MQ:

http://www.zeromq.org/




-- 
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/