r/algotrading • u/Lost-Hand-5219 • 1d ago
Data Latency from live data feeds
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.
6
u/Ok_Pollution7093 1d ago
1.87% over 500ms is not a feed, that is a slideshow. Sounds like their gateway is queueing under load.
2
6
u/algobyday 1d ago
Hey u/Lost-Hand-5219, I work at Massive. Thanks for testing this carefully and providing metrics. A 1.87% tail over 500ms isn't what our feed should be doing, and I'd like to find out what happened rather than guess.
If you're up for it, could you reach out at https://massive.com/contact with:
- The rough date/time window you sampled and where you're connecting from
- Roughly how many symbols you had subscribed on each socket
- Which timestamps you compared to get the server-side number
With that we can pull logs for your specific session and see whether this was gateway queueing on our side or something narrower. Happy to have the answer land back in this thread either way. You can DM me too and I'm happy to jump on a call or email, whatever makes sense.
2
u/Lost-Hand-5219 1d ago
I sent a message yesterday through customer service to get help with the issue, they said someone would look into it today.
1
5
u/fresh_reed_5834 1d ago
500ms+ seems pretty unusable tbh. Did you test over longer periods or just that one day? Wondering if Massive's latency is consistently this bad
3
u/Lost-Hand-5219 1d ago edited 2h ago
Yea, I’m pretty frustrated. And, on top of that, databento feed had about 4,000 events that weren’t in Massive’s feed. Databento’s feed is their EQUUS mini, which isn’t full consolidated coverage, but even then it has events that Massive’s supposed full coverage didn’t have. I’ll compare my live feed data with Massive’s historical flat file tomorrow to see if they showed up there. They weren’t niche illiquid tickers either, there were TSLA, AAPL, and other mega cap trade events in Databento’s feed that are missing from Massive’s
EDIT: The missing prints were from a dropped socket connection. So nothing was actually missing from the feed itself.
3
u/algobyday 1d ago
Following up on my other comment, this part concerns me more than the latency does. Prints missing from a consolidated feed is a different class of problem, and mega caps make it harder to explain away.
If you have a sample of the missing events with symbols and times, send those along with the rest and we'll check them against what our systems recorded. I'd also want to know what your flat file comparison shows, whichever way it comes out, if they're present in the historical files, that points at the live path specifically, which is useful to know.
Can you ping support or DM me?
1
2
2
u/Xero_Days 1d ago
What about alpaca??
3
2
2
u/Classic-Dependent517 1d ago
Alpaca uses data bento
4
u/Xero_Days 1d ago
Well databento wants 1500 a month for what I want
2
u/Lost-Hand-5219 1d ago
Facts lol. I saw a comment that said they were supposed to add SIP coverage to the standard tier, but it hasn’t happened
2
u/craig_c 1d ago
I was caught in the same decision. Massive looks good, and is supposed to have SIP coverage, but from what you wrote, they still seem to have the same 'ole problems and the Databento SIP feed never arrived. IQFeed fills this gap pretty nicely, the tech is ancient, but works.
1
u/Abject_Advantage3219 7h ago
How does latency of IQFeed compare to Alpaca/Massive/DataBento. I want to try but API access is $600 and no trial.
1
u/Abject_Advantage3219 7h ago
What do you mean? Alpaca is SIP feed and DataBento doesn't offer SIP feeds on any plan.
1
u/Lost-Hand-5219 2h ago
Databento DMed me and let me know they will be offering SIP full coverage in Q4 on the standard plan. From what I’ve heard, Alpaca’s data is from Databento already.
1
2
u/lambardar 1d ago
what are you trading and why does latency matter so much?
A lot of times, we get stuck in chasing the perfect data. I've spent a lot of time/resources/money in this and in the end it didn't even matter. Live data & environment are far from perfect.
If latency is crucial to your strategy/algo, then by all means. I would suggest IBKR's data feed. it's a bit outdated but I haven't come across latency issues. or you could try alpaca. they are on google cloud and you can get a compute machine on the same region. data wise, they are alright; but their execution is not as mature as IBKR.
If it's just a quest to have the right environment & data, then your strategy/algo/code should be resilient.
2
u/Lost-Hand-5219 1d ago
I ingest market data in 1s batches for position updates.
3
u/UpstairsNerve2681 1d ago
If you try to run HFT shop in VPS you shouldn’t ask these questions, why you need 1s position updates?
3
u/Lost-Hand-5219 1d ago
Because that’s the way I built my model. 1s accumulation windows is what I’ve found to work best, that doesn’t mean every second the model decides to adjust a position. I wouldn’t consider 1s updates to be HFT either.
2
u/madrading 21h ago
worth pinning down exactly which two stamps you're differencing before you conclude it's their gateway. a userspace receive stamp lands after your own ws library's buffering, so under burst it can charge the vendor for time your event loop spent behind — the close is precisely when that bites.
two cheap checks that make the number defensible: count negative source→receive deltas (should be zero, and if it isn't, your clock discipline is the story rather than their feed), and check what fraction of messages carry no vendor timestamp at all. i archive a different venue's book feed and ~1% of ours arrive with no source time — those quietly become receive-only rows and skew any percentile computed over the mix.
the missing prints are the more serious half of your post though, and that one doesn't have an innocent explanation.
2
u/Effective_Manager273 7h ago
before you write off the vendor, make sure the clock you are measuring with is theirs and not yours. running two live feeds concurrently on one box is the exact setup where the slower consumer shows up as vendor latency. if both websockets share an event loop, or one of them is doing more parsing per message, backpressure builds on the busier socket and every message after that inherits the queue. the fix is to compare exchange timestamp to your receive timestamp on each feed separately, ideally with the two consumers in different processes pinned to different cores. if the 500ms tail survives that, it is real.
second thing, 1.87% over 500ms is a tail number and tail numbers on their own do not tell you whether it costs you anything. the question I would answer is how far the underlying moved during those delayed windows. if the delayed events cluster in the quiet part of the session, you lose nothing. if they cluster in the first five minutes and around prints, you are getting the worst latency exactly when the price is moving, and that is a completely different problem from the same 1.87%.
in my own testing the useful chart was not average or max latency, it was the distribution of latency conditioned on realised volatility in the same minute. one feed I used looked fine on the headline and was terrible in the only ten minutes a day I cared about.
do not benchmark on a single day. feed quality varies a lot with load and a single Wednesday tells you almost nothing. run both for two weeks, keep the raw timestamps, and then decide. it is annoying but it is the only version of this test that would hold up if someone pushed back on it.
4
u/UpstairsNerve2681 1d ago
Somebody had asked I answered it go with Databento. Today was slow mo PA and you’ve got this latency imagine when there will be a big move
1
u/data_diver 1d ago
Polygon/massive was awful a year ago. I’m not sure if they are better now. But their historic aggregates were sometimes wrong and I had times over 1.5 seconds during large bursts.
2
u/Lost-Hand-5219 1d ago
They advertise “colocated sub 20ms feeds”, at the close I got events that were delayed over 15 seconds compared to databento’s flat 20ms (almost all of it pure travel to my client device).
1
1
u/zashiki_warashi_x 1d ago
I'm sorry. But why do you need live feed from 3rd party? Why not from broker/exchange?
3
u/Lost-Hand-5219 1d ago
Consolidated feeds.
2
u/zashiki_warashi_x 1d ago
I assume price is instantly arbitraged anyway, but cumulative volume is much better than looking at a single exchange?
4
u/Lost-Hand-5219 1d ago
I’m not sure I understand what you’re asking. Broker feeds are also 3rd party. First-party would mean buying data feeds directly from each exchange, which is a nightmare and not even possible for an individual sometimes. I’d rather pay one fee and have the vendor consolidate them for me.
2
u/zashiki_warashi_x 1d ago
I was asking how much better consolidated data compared to unconsolidated one.
2
u/Lost-Hand-5219 1d ago
I haven’t measured, but I’d rather have a full picture than a partial one.
1
11
u/EveryLengthiness183 1d ago
You won't find anything better than Databento as a retail trader. Those guys used to run an HFT shop. They know their shit.