Skip to content

Latency Benchmark

In one line: on a single host, the godzilla.dev local software path — from a market-data event entering the journal to a local order report being generated — completed with a run-level median of 121–135 µs and a run-level p99 of 435–662 µs, across five runs of 900 measured order cycles each.

Everything below — the methodology, the scripts, the raw per-event records, and the exact commit — is published in the public repository. So is the list of things this benchmark does not measure, which is longer than the list of things it does.

What this measurement is not

This is a single-host software-path microbenchmark. It excludes network transport, exchange gateways, matching-engine processing, order acknowledgements, fills, and queue position. It says nothing about strategy profitability, fill probability, connector breadth, or long-duration reliability. It is not a comparison with any other trading framework, and it is not a production service-level objective.

In a deployed system, your network path to the exchange will normally dominate this number unless you are co-located.

Why we published it

Every trading framework says it is fast. Almost none of them define what they measured, where the measurement starts and stops, or what they left out.

We think a latency claim is only meaningful if it comes with event boundaries, an artifact, and an explicit scope. So this page states the number, the method, and the limitations together — and the raw event records are in the repository so that anyone can re-run the benchmark or dispute the result.

What was measured

The measured path is one full local cycle:

Depth (market data process)
  → native C++ strategy callback
  → OrderInput
  → trade process
  → local OrderReport

All timestamps are journal frame generation times on one host, extracted from the framework's persistent event records after the run — synchronous trace writing is disabled in the measured path, so measurement overhead does not sit inside the interval being measured.

The primary metric is depth-to-local-order-report latency. It is not exchange-acknowledged order latency, and it is not fill latency.

The strategy in the measured path is native C++: its depth callback alternates side, selects the corresponding displayed best price, constructs one limit order, and submits it. Python is used for process bootstrap but is not on the measured callback path. A Python-path benchmark answers a different question and is deliberately not blended into this result.

Results

End-to-end local path

Aggregation unit is the benchmark run (five runs, 900 retained cycles each, 4,500 observations total).

Percentile Minimum Median Mean Maximum
p50 121.1 µs 121.3 µs 124.9 µs 135.4 µs
p90 256.0 µs 281.4 µs 278.0 µs 298.6 µs
p99 434.8 µs 447.3 µs 485.9 µs 662.0 µs

The median is stable across runs. The tail is not: p99 varied substantially run to run, and run-level maxima ranged from 719.9 µs to 1,450.0 µs. Reporting only the best run would overstate predictability, so all five are published.

Stage decomposition

Stage-specific percentiles are marginal quantiles and are not additive.

Stage p50 (median / mean) p90 (median / mean) p99 (median / mean)
Depth → order input 99.8 / 100.0 µs 147.2 / 147.6 µs 336.2 / 335.6 µs
Order input → local report 22.3 / 26.3 µs 131.4 / 131.5 µs 187.7 / 206.5 µs
End-to-end local path 121.3 / 124.9 µs 281.4 / 278.0 µs 447.3 / 485.9 µs

The median is dominated by the depth-to-order-input stage. At higher percentiles both stages contribute variability. One run contained a 1.334 ms maximum in the order-input-to-report stage; the current instrumentation cannot attribute that excursion to a specific scheduler, cache, wake-up, or runtime cause, and we say so rather than filtering it out.

Configuration

Item Configuration
CPU Intel Core i7-1360P, 12 cores / 16 logical CPUs, 18 MiB L3
Operating system Linux 6.14.0-37-generic, x86-64
Runtime topology master, ledger, native mock MD, native mock TD, native C++ strategy
Logical CPU affinity master=0, ledger=1, MD=2, TD=3, strategy=4
Market-data interval 300,000 ns (≈3,333 synthetic depth events/sec)
MD wait policy sleep followed by a 100,000 ns spin window
Trace mode journal only; benchmark CSV tracing disabled
Input per run 5,000 depth events
Orders per run 1,000
Warm-up exclusion first 100 matched cycles
Retained observations 900 per run (4,500 total)
Independent repetitions 5

Note that the host is a laptop-class CPU, not a tuned server, and that the median measured path is shorter than the 300 µs input interval — so this characterises low-utilisation latency, not sustained saturation behaviour.

Known limitations

These are stated in full in the accompanying paper. In short:

  • Sample size. Five runs and 4,500 observations are an engineering baseline, not a basis for stable extreme-percentile estimation. A stronger study would pre-declare 30+ repetitions with longer runs and confidence intervals.
  • Event causality. Depth-to-order-input matching uses symbol, side, price and temporal ordering rather than a propagated causal event identifier. A source event ID should be carried through the order lifecycle before burst and multi-symbol experiments.
  • Workload realism. Synthetic constant-rate top-of-book messages do not reproduce clustered arrivals, exchange-specific decoding, burst backlogs, or order-book reconstruction.
  • Short duration. Too short to characterise thermal behaviour, journal rollover, memory pressure, or recovery after faults.
  • Missing environment controls. Compiler flags, CPU governor, C-states, hybrid-core mapping, and background load were not captured in the artifact. Results on other hardware may be higher or lower; no direction is inferred.
  • No external exchange path. Sockets, exchange protocols, gateways, matching, acknowledgements, fills and queue position are intentionally excluded.
  • No comparative evaluation. This is not a benchmark against Hummingbot or any other framework. A fair comparison would require version-pinned implementations, identical workloads and strategy semantics, disclosed tuning on both sides, and independent review. We would welcome co-designing one.

Reproduce it

The benchmark launch scripts, journal analyzer, multi-run aggregation, plotting tools, and stored result artifacts are in the community repository.

If you re-run it on different hardware and get a different answer, that is a useful result — open an issue with your configuration and we will link it here.

Does this number matter for your strategy?

Often, no. Be honest about which case you are in.

Internal software latency probably does not matter much if you hold funding-rate positions across settlement cycles on liquid pairs, size is moderate, and your edge is measured in hours.

It starts to matter if you leg into positions in the final minutes before funding settlement while spreads widen, you trade less liquid pairs where the mark price moves against you mid-hedge, or you quote both sides of the book all day and queue position is the edge.

It matters less than you think if you are not co-located: a millisecond-scale network path to the exchange will dominate a microsecond-scale local path. Fixing the second without the first buys little.

  • Architecture — the process-isolated md / strategy / td model and the journal-based shared-memory event path: Architecture documentation
  • Paper — Low-Latency Execution Infrastructure for Funding-Rate Arbitrage: Architecture and a Reproducible Single-Host Benchmark, published with the source repository
  • Enterprise deployment — private deployment on your own infrastructure: Enterprise