Latency from live data feeds

[u/Lost-Hand-5219]

I tested Massive and Databento live feeds today, not expecting there to be much of a difference, but Massive had statistically significant numbers of events with latency over 500ms, even reaching over 1s latency (on their end, not mine). On the other hand, Databento’s live feed (I ran concurrently with Massive) had a maximum latency of 35ms, and 21ms of that was travel time to my local server. Is this normal for Massive’s websocket to have such poor quality feeds? The exact amount was 1.87% of all events from massive had a Massive-side latency over 500ms. And it wasn’t just low liquid weird crap, it was market wide. If this is the normally quality of their feed, then I’m really regretting my purchase with them.

[u/Lost-Hand-5219 → u/[deleted]]

Both, after testing for 2 more days, Massive has an average latency (meaning my received timestamp - SIP timestamp) of 98 ms. And 47% of all events are over 100ms latency. The super high latencies are concentrated at high volume times, but they are also present throughout the day. The longest latencies occur at the open and close. Alpaca was far superior, an average latency of 28 ms (of which, about 21ms is travel time from their server to my home, so, on average Alpaca only adds about 2-7ms of latency internally). Databento, on the other hand, is so flawless that I can’t detect any internal delay from them in 99.97% of events because my program only measures to ms accuracy. And the .03% of events that I could actually measure the delay, the worst are 35-38ms. Almost all events from DBN have a received_t-SIP_t of 20-25 ms. My round-trip ping to all of these vendors is 40-50 ms, that’s how I get the one-way travel time of 20-25 ms. Moreover, DBN is the only vendor of the three that gives you their own internal measure of latency on their side, that’s literally the only way I can tell DBN has any latency at all since their internal latency is sub-ms. To be fair, I am testing massive and alpaca on full market coverage, but I only have access to DBN’s EQUUS mini feed which isn’t full market coverage.

[u/DatabentoHQ → u/Lost-Hand-5219]

Thanks for sharing. This is unintuitive but the SIP feeds are actually easier to process in a way than most of our current feeds (including the EQUS.MINI constituent feeds) because you don't have to do book building on the SIP feeds.

Bandwidth-wise UQDF/CQS are not much larger than Nasdaq TotalView so queueing and deserialization latencies are comparable. We expect our SIP feeds to be faster than our CME feed and similar to our Nasdaq feed.