Back to product

Methodology · benchmark tiers

Every number, and what produced it.

BQL Engine figures come from a controlled single-node ITCH replay on isolated Linux cores using the internal harness. Different BQS materials quote different throughput numbers because they measure different tiers of work. The table below reconciles them.

Throughput tiers

Benchmark tierIncluded workThroughput
Tier A — match-only microbenchOrder-matching hot path only. Pre-parsed events in memory, no decode, no book snapshotting, no logging.≈1.96M events/sec
Tier B — in-process pipelineDecode + book build + match, single process, no evidence emission or metrics export.≈1.23M events/sec
Tier C — complete pipelineDecode + book build + match + metrics + digest computation + evidence emission. This is the tier quoted in pilot work.≈1.20M events/sec
Replay ingest ceilingDeterministic replay feed rate — how fast recorded events are streamed into the engine, excluding downstream work. It is an input-side ceiling, not end-to-end system throughput.≈8.4M events/sec

Latency figures quoted on the product page (42 µs p50 / 187 µs p99) are Tier C — complete-pipeline, end-to-end per-event latency in the same environment.

Run metadata recorded for every figure

Commit SHA
Recorded in manifest.yaml of each bundle; every published figure is bound to one commit.
CPU / hardware
Single-node x86-64, SMT disabled, benchmark threads pinned to isolated cores. Exact model recorded per run.
Kernel
Linux 6.x with isolcpus + nohz_full on the benchmark cores.
Compiler & flags
C++20, -O3 with native architecture targeting. Exact compiler version and full flag string recorded per run.
Workload
Recorded NASDAQ ITCH session replay. Message counts and per-type composition recorded in summary.txt.
Warm-up
Discarded warm-up pass before measurement; measured passes begin from a steady-state cache and allocator condition.
Runs
Latency percentiles from repeated measured passes; digest consistency reported across N=100 replays of identical input.
Raw measurements
bench.jsonl contains per-run raw samples; metrics.prom contains exported counters.
Calculation
Percentiles computed from the full sample set (no interpolation across runs); throughput = measured events ÷ wall-clock of the measured pass.
Bundle hash
SHA3-256 over the canonical file list in manifest.yaml; the digest value is reproduced by re-running the pipeline on the same input.

Exact reproduction sequence

shell · public harness
git clone https://github.com/jblanc86-maker/blanc-quant-lob-engine
cd blanc-quant-lob-engine
git checkout <commit-sha-from-manifest.yaml>

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

# pin to isolated cores, run the measured pass
taskset -c 2,3 ./build/bql_bench \
  --input data/itch-sample.bin \
  --tier complete \
  --warmup 1 --runs 10 \
  --emit-bundle out/

# verify the canonical digest of the produced bundle
sha3sum -a 256 -c out/manifest.yaml

The public harness runs scaled functions. Enterprise orchestration, CI gate contracts, and full evidence-bundle emission are part of the pilot.

What “verified” means here

Digest mechanism

A canonical serialisation of terminal book state and the emitted artifact list is hashed with SHA3-256. Two runs match only if every ordered state transition matches. The hash is recomputed by any third party from the same inputs — it is hash-verified reproducibility, not an attestation of authorship.

Audit posture

BQL Engine is not certified against any compliance standard. It produces reproducible, hash-verified engineering evidence that can support internal audit, risk, and diligence reviews. Cryptographic signing of bundles with customer-held keys is a pilot-scoped option, not a default claim.