Estimating Order Latency When Counterparty Clocks Are Unreliable
Summary
The discussion addresses measuring latency between a trading server and liquidity providers when their FIX SendingTime values differ from the local clock by around tens of milliseconds, despite the local server using SNTP. The central caution is that a counterparty timestamp may be inaccurate, and apparent timestamp differences should not be treated as a reliable measurement of network or execution latency. The replies describe larger discrepancies in practice, including inconsistent clocks across counterparties and even across computers handling different symbols.
One proposed alternative is to keep the local clock well synchronized and measure an order round trip using local events, such as the time an order is sent and the receipt of a pending-new or new execution report. This estimates order-response latency rather than isolating true one-way network latency, so it is an imperfect proxy. The exchange offers practitioner observations and an operational measurement idea, not benchmark data or a standardized synchronization method. It also mentions NTP daemon configuration, but provides little detail for diagnosing or validating clock accuracy.
Key ideas
- Counterparty FIX timestamps may be inaccurate, so timestamp differences do not necessarily measure true latency.
- Clock errors can vary across counterparties and across machines within the same trading operation.
- A locally recorded order-send time and response-report time can estimate order round-trip latency.
- Round-trip order timing is a practical proxy, but it does not isolate one-way network delay.
- Keep the local clock synchronized while treating external timestamps cautiously.
Tags
Full text
# FIX latency and clock syncronization # FIX latency and clock syncronization We are trying to see latency from our server to different LPs . For that we are checking sendingtime value (from them) and current clock in our server. What we saw is difference of +-20ms between them and us. BTW, We are syncing our server with a SNTP. Is this normal? can anyone tell his/her experience on this? Thanks ## Answer by TomTom (score 2) https://quant.stackexchange.com/a/29992 It is normal. The finance industry is seeing a lot of incompetence. You can NOT realy on the sending party having a highly accurate timestamp - I have seen discrepancies up to more than a second during normal operation. Things hopefully get better once Windows 2016 is widespread as this naturally out of the box synchronized to 1ms accuracy. But at the moment... ...my advice is to rely on other means. It is QUITE hard to measure true latency, but you can measure order latency. You basically need something that round trips from your end. Keep your side well synced, and then "cope with it" somehow. Third party timestamps will be off, because while you can follow best practices, many others do not. My current most active trading partner uses diferent computers to handle different symbols. The ticks are SIGNIFICNATLY off - as can be ween by timestamps moving backwards between symbols. Nothing I can do about this. ## Answer by user18399 (score 0) https://quant.stackexchange.com/a/22025 Have you tried installing the ntp daemon ntpd (which calculates the drift of your system clock and continuously adjusts it)? If so check sudo ntpd -qgddd ## Answer by Daniil (score 0) https://quant.stackexchange.com/a/31786 It is amazing how careless financial industry is given the amount of oversight and regulation. We've had to disable time check with some parties simply because they refuse to maintain proper time (they just don't give two ****s about that kind of thing). I've come up with another method to estimate the delay. It works for us and our purposes. Record the time order is sent to counter party and compare with when either PENDING NEW or NEW execution report is received. Obviously this isn't perfect for you needs since it doesn't really measure time latency, but thought to share.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.