Syncing Laptop Time to Atomic Time

Discussion in 'Hardware' started by CPTrader, Feb 7, 2012.

  1. Your platform would have to be an incredibly poorly architected piece of software for it to rely on the clock on your local machine for anything critical. Any market data messages should use the timestamp provided by the data provider. All order related messages should be timestamped by the broker/FCM infrastructure upon transmission/reception.

    It is precisely because the clock on a machine can be altered whilst an application is running that it should never be relied upon by 3rd party apps for critical operations.

    Try connecting to your broker's demo/test environment (if available) and then changing the clock. If your platform doesn't handle it gracefully (eg. crashes, hangs or generally starts to misbehave) then you have to start asking questions about the quality of the product.
     
    #21     Feb 9, 2012
  2. P.S. Obviously every trader does need an accurate local clock so they can be aware of impending significant market events (eg. open, close, news release) when making execution decisions. For this purpose Dimension4 is excellent. Start it up on a low priority thread (so it doesn't hog CPU cycles in a fast market just when you need them) and you can keep your clock millisecond accurate with very little hassle.
     
    #22     Feb 9, 2012
  3. kittermh

    kittermh

    Thanks for this intel, all, I had the very same question!
     
    #23     Feb 9, 2012
  4. Many Thanks to all who contributed. Very much appreciated.
     
    #24     Feb 9, 2012
  5. Craig66

    Craig66

    #25     Feb 9, 2012
  6. Agree 100%.

    I exchanged IM's with a guy today asking him about safe latency - usually the ultra low latency guys run "raw" (like raw as in without a condom... or without a firewall since that slows you down 10-500 milliseconds) but how do we "screw with a condom and be just as good"?

    (sorry for the vulgar example but most will understand)

    So if your running raw a change on the local machine can be huge - catastrophic. If you aren't and you have buffers, TCP data, local machine supported broker platform, etc. then you could set your local time to 1929 30 second prior to the crash and orders would keep executing.

    These are two extremes however what a time sync really suggests is the difference between a CPU clock cycle (3.0ghz = how many "cycles per second") and real time. A computer ALWAYS estimates a curve - so there is a legit break. A computer can't ever exactly reproduce a curve - think of pixels vs. a true drawn curved line. Up close the pixels look like a staircase while a line drawn by hand will always be smooth and continuous. Computers are getting closer (the steps on the staircase are getting shorter & smaller) but they are still 90* angles (or small segmented straight lines trying to build a curve). There will always be a break and depending on environmental factors such as temp, humidity, die consistency, no two CPUs are the same therefore every machine needs to be told what time it really is (irony is that an inaccurate machine is telling another inaccurate machine what time it is).

    That said 99.99999% of the world is sitting in some random office and has zero need for an intra-day update in their time servers. Google "how fast can the human eye see" and you'll learn it's between 15 and 20 milliseconds. That's how long the relay takes between the light hitting your retina and your brain understanding it. If you are worried about your machine's internal clock being off by sub-milliseconds I really think you are chasing something that's fairly insignificant.

    Everything I have syncs weekly to whatever server is most relevant - but never daily or hourly. The sync runs just after a full virus scan (if there is AV on that machine) and Windows Update.

    Probably a wasted effort but makes us feel good. I'll retrieve the batch files & instructions on Saturday and post up soon.
     
    #26     Feb 10, 2012