Algostream_backtest.LatencyExecution latency simulation.
Venue.base_latency_us is read by nothing else. This module is its first consumer. Without it a backtest fills against the very tick that triggered the decision, which is the single most flattering and least realistic assumption a simulator can make.
Four delays, all in event time:
decision_to_venue_ns — strategy emits an action → the venue receives itvenue_match_ns — venue receipt → the order is eligible to matchfill_to_strategy_ns — the fill happens → the strategy is told about itcancel_to_venue_ns — a cancel is issued → the venue applies it (a cancel racing a fill is how real orders get filled after you tried to pull them, and this reproduces that)Jitter is drawn from the caller's Rng.t. The engine holds a separate substream for execution noise from the one driving the price path, so changing the latency model does not shift the data a Monte Carlo comparison runs on — common random numbers.
module Venue = Algostream_order_management.Venuemodule Rng = Algostream_rng.Rngval zero : tAll delays zero. For unit tests that want to isolate the fill logic, and for the "perfect execution" upper bound a strategy's real result should be compared against.
Derive from a venue's published latency. decision_to_venue_ns seeds from venue.base_latency_us × 1000; the match and inbound legs default to a quarter and a half of that respectively, which is the usual shape (matching is fast, market data dissemination is not). Override any of them explicitly.
Outbound delay for a new order: decision_to_venue_ns + venue_match_ns, jittered.
Inbound delay for a fill report: fill_to_strategy_ns, jittered.
val to_string : t -> string