Latency is the most-quoted and least-defined number in market data. "Ultra-low latency" means nothing without a definition of what was measured, from where, at which percentile. If you are choosing a provider on speed, you need to measure it yourself — and know what you are looking at.
Averages hide the pain
Never evaluate a feed on its mean latency. The average is dominated by the easy cases and says nothing about the moments that hurt. What matters is the tail: p50 tells you the typical experience, p99 tells you how bad the bad ticks are, and p99.9 tells you what happens exactly when the market moves and every message arrives at once. A feed with a great average and a terrible p99 will fail you precisely when it counts.
Measure end to end, not gateway to gateway
A vendor’s "sub-millisecond" is usually measured inside their own network — capture gateway to their egress. That is a real number, but it is not your number. What you care about is exchange timestamp to the moment your application decodes the message, including the network path to wherever your compute actually runs. Measure from the exchange-provided timestamp on the message to your own receive timestamp, and you will get an honest figure.
Mind the clocks
The subtlest trap is clock skew. If your server clock and the exchange clock disagree by two milliseconds, your latency measurement is wrong by two milliseconds — and can even go negative, which is a useful sign your clocks are lying. Discipline your hosts with PTP or good NTP before you trust a single latency number.
What good looks like
A serious provider will tell you where they measure, publish percentiles rather than averages, and let you verify in-region. Pig Data runs co-located gateways and a binary WebSocket protocol for a median in-region delivery under a millisecond (illustrative) — but the number that should convince you is the one you measure yourself against your own clock.