Anatomy of a run
Three processes
Every algo run is three cooperating processes:
- The engine (
bin/algo) – the conductor. It owns the clock, the bar loop, and the fill simulator. - A data adapter – a program that serves market data. The engine spawns it, asks what it can do, and requests bars (or raw trades) over the data wire.
- Your strategy – spawned next, fed the bars one by one over the strategy wire. After each bar the engine waits for your response (orders, or nothing) before moving on.
Both wires are negotiated automatically: each side says what protocols it speaks and the engine picks the best mutual one (a binary protobuf wire, a raw-DBN wire on the data side, and a plain-text CSV wire as the lowest common denominator). You saw it in the report: stdio-dbn-v1 to the adapter, stdio-pb-v1 to the strategy. You never have to care, but the Other languages chapter shows how thin the CSV wire is if you want to write a strategy in another language.
Reading the run report
Line by line, from the hello run:
| Line | Meaning |
|---|---|
Algolang run run-MSFT-1m | The run ID. Deterministic by default (run-<symbol>-<interval>, with a continuous symbol slugified: run-fut-xcme-es-1d); set your own with --run-id or a config-file name. |
adapter: | Adapter binary and the data-wire protocol negotiated. |
strategy: | Strategy binary, its self-reported name, and the strategy-wire protocol. |
instance: | The one strategy instance, the series it saw, and how many orders it submitted. |
request: | What was asked of the adapter (symbols, schema, bar kind). |
coverage: | The finest bar granularity the adapter’s data can honestly support over the window (see Data). |
data: | Records fetched, bytes moved, fetch throughput. |
bars: | Bars delivered to the loop, plus any warmup history (see Writing a real strategy). |
simulator: | The fill simulator’s conventions and account outcome (see The fill simulator). |
phases: | Wall-clock breakdown of the run. |