Colocation Latency Benchmark
Every latency figure is a subtraction between two clocks. This page states the clocks first, then the numbers, then what they do not cover.
All figures were measured on 2026-09-21 from a host in the same Hetzner facility as the venue, against production. The measuring host and the exchange are separate machines. Nothing here is a capacity guarantee or an SLA.
This does not replace the remote measurements
The HFT Guide and Live Verification report an external client's figures from Vienna on 2026-09-13: a FIX 4.4 order acknowledgement at 29.9 ms over a 29.5 ms network round trip. Those numbers remain correct for a client at that distance. They measure a different thing: distance plus processing, where distance dominates.
This page separates the two terms. Read both.
Clock discipline
Both machines synchronise to NTP:
| Host | Offset from reference time | RMS |
|---|---|---|
| Measuring host | 3.8 µs | 38 µs |
| Exchange | 616 µs | 234 µs |
The offset between them is therefore about 0.6 ms, with roughly 0.25 ms of uncertainty. That figure is applied to every absolute number below.
A convenience estimator — asking GET /api/v1/health for its own timestamp and
comparing — returned a 51.8 ms offset at a 128 ms round trip on the same run. It
travels through a CDN and includes a TLS handshake, so it was discarded. If you
reproduce this measurement, do not derive your offset that way.
Network baseline per lane
TCP connection establishment, 30 samples per endpoint. This is one round trip and carries no application work.
| Endpoint | p50 | p90 | min |
|---|---|---|---|
api.sentico-labs.xyz:443 (via CDN) | 21.67 ms | 33.61 ms | 11.20 ms |
md.sentico-labs.xyz:9002 (direct) | 0.51 ms | 1.99 ms | 0.40 ms |
md.sentico-labs.xyz:9003 (direct) | 0.46 ms | 0.50 ms | 0.40 ms |
bsl.sentico-labs.xyz:9001 | 0.48 ms | 0.52 ms | 0.40 ms |
fix.sentico-labs.xyz:9878 | 0.44 ms | 0.48 ms | 0.37 ms |
fixp.sentico-labs.xyz:9879 | 0.47 ms | 0.59 ms | 0.35 ms |
TLS handshake on top, 10 samples:
| Endpoint | p50 | min |
|---|---|---|
api.sentico-labs.xyz:443 | 33.31 ms | 27.73 ms |
md.sentico-labs.xyz:9002 | 4.96 ms | 4.52 ms |
md.sentico-labs.xyz:9003 | 5.60 ms | 4.61 ms |
The four binary lanes are DNS-only and resolve to the venue host directly.
api.sentico-labs.xyz resolves to a CDN edge, so traffic from inside the
facility leaves it and comes back — which is what the 21.67 ms measures.
Market data delivery
Time from the server's frame timestamp to arrival at the client, 300 s across eight markets, clock offset applied.
| Route | p10 | p50 | p90 | p99 | min |
|---|---|---|---|---|---|
api.sentico-labs.xyz (via CDN) | 7.82 ms | 8.55 ms | 9.99 ms | 14.99 ms | 7.25 ms |
md.sentico-labs.xyz:9002 (direct) | 1.30 ms | 1.80 ms | 2.26 ms | 4.56 ms | 1.02 ms |
md.sentico-labs.xyz:9003 (direct) | 1.25 ms | 1.72 ms | 2.21 ms | 7.53 ms | 0.99 ms |
Cross-checked without any clock
The same frames were matched across both routes by (channel, marketId, seq)
and their arrival times compared. One clock stamps both arrivals, so any offset
cancels out entirely.
| Run | p10 | p50 | p90 | p99 |
|---|---|---|---|---|
| 300 s, 8 markets | 5.85 ms | 6.84 ms | 8.19 ms | 13.59 ms |
| 240 s, 5 markets | 11.36 ms | 12.40 ms | 14.08 ms | 20.82 ms |
Positive means the direct route arrived first. It arrived first on effectively every frame in both runs — the tenth percentile is already above zero.
The first run agrees with the absolute table to 0.1 ms: 8.55 − 1.80 = 6.75 against a measured 6.84. The second run shows roughly twice the difference, which is variation in the CDN path rather than in the venue.
What these numbers do not cover
Across 964 frames carrying identical sequence numbers on both routes, not one carried the same server timestamp. The two stamps differed by 125 ms at the median and by over 900 ms at the extreme, while delivery time stayed steady under 7 ms.
The timestamp is therefore applied shortly before transmission, per publishing process — not when the engine applies the event. A market-data figure derived from it measures the last hop, not the path from a trade occurring to a client seeing it. That larger part is currently not instrumented end to end, and it will be published when a stage-by-stage measurement chain exists rather than extrapolated from this one.
No order acknowledgement was measured from inside the facility. Doing so places live orders on production, so this page reports the network baseline for the order lanes and nothing beyond it. The in-house processing term that follows from the 2026-09-13 Vienna figures — 29.9 ms acknowledgement over a 29.5 ms network round trip — is a derivation, not a colocated measurement. Treat it as such until it is measured directly.
Two runs, one day, one location. Latency measured at one moment is not latency under your load, your session count or your subscription pattern.
Reproducing it
The measurement used the Python standard library only, with a minimal RFC 6455 client so the arrival timestamp is taken when the final byte of a frame is read, and credentials passed on standard input rather than through argv or the environment. To repeat it:
- Establish your own clock offset against a reference, not against the venue.
- Sample TCP connection establishment per endpoint, at least 30 times.
- Subscribe to the same markets over both routes from one process and match
frames by
(channel, marketId, seq). - Report the paired arrival difference as the primary figure and the absolute delivery time as the secondary one.
Steps 3 and 4 matter: the paired figure is the only one that carries no clock error at all.
Related
- Direct Market Data — how to connect to the route measured here
- HFT Market-Maker Guide — lane semantics and the remote measurements
- Live Verification — dated production runs