Recorded-session performance

The October 23, 2026 experiment measures a recorded SPY options session through Feed's publisher, md:v2 session log and Source reader. Unpaced publication replay measured 1.86–1.91 million events per second. At 100× recorded pace, scheduled-arrival to reader p99 was 175–180 microseconds across both reader modes. These figures describe different pacing configurations.

Twelve full-session runs verified 5,788,340 events each, with zero refusals and 47 prepared file rollovers in every run. Each reader/pace combination ran three times. The first run is included; each run's percentiles and maxima are retained.

Results

Ranges below are the minimum and maximum of the three run-level results. They are not pooled percentiles, confidence intervals or performance guarantees.

At 100× the input schedule determines the reported 23,819 events/s; that number is not a saturation limit. Recorded bursts remain in the workload, so paced reader-visible latency includes waiting behind earlier events in a burst.

First publication/open took 244.930–307.933 µs. The worst subsequent publication sample was 386.104 µs. Every run had zero venue-thread major faults; minor faults and context switches are retained in the downloadable data.

Workload and host

• Capture: Databento OPRA.PILLAR, October 8, 2026; 350 explicit SPY same-day option contracts. The ET-session interval is [1791432000000000000, 1791518400000000000) nanoseconds since epoch.
• Independent inventory: 13,160 definition records, 3,532,962 cbbo-1s records and 1,127,689 tcbbo records. Each CBBO record produces a quote; each TCBBO record produces a quote and trade. The expected normalized count is therefore 3,532,962 + 2 × 1,127,689 = 5,788,340. Definitions have a wider expiry scope; selected identities and market records are checked against the 350-contract manifest. The official databento-dbn 0.71.0 decoder and zstandard 0.25.0 inventory the capture independently of Feed's mapper.
• Host: Intel Core i9-10920X, 12 physical cores / 24 logical CPUs, 64 GiB installed RAM, Linux 7.2.10. Rust 1.97.1 release build.
• Placement: publisher on CPU 2, reader on CPU 14. These are kernel-isolated SMT siblings of one physical core. Log housekeeping and read-ahead exclude both. Thread affinity was inspected during replay. The inspected governor was performance with intel_pstate; frequency was not fixed.
• Log: tmpfs, 16 MiB files, 8 MiB pretouch, one reader. Spinning and blocking readers each ran unpaced and at 100× recorded pace, repeated three times in that order.
• Other load: GitLab CI containers were absent; numerical research continued. Compilation finished before measurement, and no compilers appear in the before/after host snapshots. CPU pinning does not remove memory, cache or thermal contention from other work.

Timing boundaries

Publication replay throughput divides the event count by elapsed time from entry to the first publication call through return from the last. It includes first-open/startup coordination. History loading, decoding, normalization and final offline verification are outside that interval.

Publication latency times each publisher call. Reader-visible latency ends when the reader observes the event's final frame. Its start is publication call entry for unpaced replay and scheduled arrival for paced replay. It includes publication and reader lag; it is not a pure post-publication transport delay.

Latency percentiles exclude the first event and contain 5,788,339 samples per run. The first publication/open cost is reported separately. Percentiles select observed values using exact nearest rank: rank = ceiling(p × n), counted from one. The displayed ranges span each run's percentile; no percentile is computed by averaging other percentiles.

These clocks do not measure provider-to-consumer latency. In particular, CBBO's ts_event refers to its last trade, not the quote, so it is unsuitable for quote exchange-to-reader latency.

Resources

Peak whole-process RSS was 2,017,428 KiB (1.924 GiB). At 100×, average whole-process CPU was 190.5–191.4% for spin and 145.1–146.4% for block, where 100% represents one logical CPU. GNU time supplies elapsed/user/system time, RSS, faults and context switches. These whole-process measurements include history loading, replay pacing and verification. The replay pacer busy-waits; these numbers are not live-feed CPU budgets.

A supplemental five-second sampler observed up to 776.195 MiB of allocated tmpfs log storage. It started during the first paced blocking run, missed some cases and ended with status 143. Its samples are point observations, not a certified peak or upper bound. The campaign and per-command resource records completed successfully. RSS and tmpfs allocation must not be added as a precise RAM total: resident mapped log pages can appear in both.

Reproduction and evidence

The measured, unreleased candidate is d1e61d1ad59f8d03f7d9319e08864d23be6d162e. Release executable SHA-256: ce16d3e9dcbe5481265560102f07fa6c92314bc07f0c6759ae0a60d7377870e2.

The campaign built in fresh, run-owned Cargo output, then passed 20 exact named regression tests, four small positive CLI replays, two unmappable-input rejection controls and twelve full-session replays: 39 checks including the build. Raw input and output hashes were rechecked after measurement. Run-owned build and session-log directories were removed after the receipt was written.

With a clean candidate checkout and the retained licensed capture/inventory, the campaign runner uses:

CARGO_BUILD_JOBS=4 CARGO_PROFILE_DEV_DEBUG=0 \
python3 scripts/run-foundation-controls.py \
  --repo "$CANDIDATE" --target-dir "$BUILD_PARENT" --out "$RECEIPT" \
  --opra-capture "$CAPTURE" --opra-inventory "$INVENTORY" \
  --venue-core 2 --reader-core 14 --scratch-dir /dev/shm --repetitions 3

Download all twelve runs, exact nanosecond values and provenance. The public receipt contains measurements and hashes, not licensed market records, workstation paths or process lists. It identifies the original runner and receipt.

Scope

This is a single-venue, single-reader publication characterization. The independent record count and replay checks establish internal accounting for this captured input; they do not establish provider completeness or every normalized field's correctness. The 100× cases are accelerated replay, not recorded-pace acceptance.

Massive SPY, concurrent venues/readers, live recovery, first-receipt freshness, front-month and arbitrary-expiry capacity, and the complete Crucible strategy path require their own evidence. Foundation qualification and numeric acceptance limits remain open. Tmpfs logs do not survive host or power loss.