Skip to content
All library documents

Ordering Level 2 Messages with Mixed Timestamp Precision

Article Quant Q&A · Author: QMath
Read the original

Summary

The document describes a data-quality problem in reconstructing an exchange order book from snapshots and updates. Updates overwrite the size at a price level, and the feed provides both provider-received times and exchange event times. Received times have nanosecond precision, while update event times have millisecond precision; snapshot event times appear to copy the received timestamp. Latency means the two clocks may not agree, complicating chronological replay.

The author asks how to order messages mostly correctly, including whether to round timestamps or convert milliseconds to nanoseconds. The document does not supply a remedy or report an empirical comparison. Its practical lesson is that timestamp precision and timestamp accuracy are distinct, and fabricating finer precision cannot reveal the true ordering of events within a millisecond. Any reconstruction method must account for the feed's timestamp conventions and latency; the source alone does not establish a reliable tie-breaking rule.

Key ideas

  • The feed combines snapshots with complete-overwrite updates at individual price levels.
  • Received timestamps and exchange event timestamps differ in both latency and precision.
  • Snapshot event times appear to be copied from provider receive times, unlike update event times.
  • Converting millisecond values to nanoseconds changes their representation but does not add event-time information.
  • The document raises the ordering problem but does not provide a validated solution.

Tags

CryptoMarket microstructureHigh-frequency tradingExecution
Full text
# Analyzing Level 2 Order Book Messages with Differing Units of Time?


# Analyzing Level 2 Order Book Messages with Differing Units of Time?












I have a stream of level 2 order book messages for a trading pair on an crypto exchange from this provider. Included are snapshots of the order book at various times as well as updates to the order book. The order book updates are complete overwrites at the price level specified, not deltas.

For each message, there is a unix time of when the message was received by the provider as well as a unix time for when the event occurred on the exchange. The messages are subject to non-negligible latency due to volume of the .

The messages are subject to non-negligible latency due to volume of said trading pair meaning that received times and event times do not align. It seems that for each snapshot event, they record the same time for the received and event times while for the update events, they use the event time as reported by the exchange.

The problem is that the received timestamps are specified to nanosecond precision while the event times are specified in milliseconds. Additionally, the event times for the snapshot messages are specified to a precision of nanoseconds as they are specified to be the same as the received time for that message.

I realize that given this data, using the supplied event times for each message might be my best choice/I should try to perhaps find data that I can interpret easier, but I would like to use this data if possible.

What ways would I be able to address/remedy this so that I can order the messages in event time in at least a mostly-correct way? I am unsure of rounding down the update event times to the nearest millisecond and don't know which direction I would go. I also could just convert the update event millisecond times to nanoseconds, but this feels like I am messing with the data since that implies that we know that that event occurred at that precise nanosecond which we don't know due to differing resolutions.

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.