itxprashant/csot-26-low-latency

Purpose and Structure

This is a five-week Linux/C++20 low-latency systems curriculum culminating in a miniature quantitative-trading data path. Each week combines ordered instructional material with an independently judged implementation challenge. The repository is educational content plus CMake-built C++ project skeletons, not a deployed application.

Primary navigation starts at README.md, then each weekly overview such as week-1/README.md through week-5/README.md.

Week 1: Strategy Runner Foundation

Week 1 establishes memory/measurement concepts and the reference strategy boundary. The project defines histogram and strategy interfaces for a runner that consumes ticks, verifies decisions, and measures per-decision latency.

Key contracts and implementation boundary:

• week-1/project/include/strategy.hpp

• week-1/project/include/histogram.hpp

• week-1/project/STRATEGY_SPEC.md

The strategy implementation is intentionally replaceable; sample implementations illustrate correct versus incorrect behavior under the fixed spec.

Week 2: Cache Simulation Challenge

The first standalone ranked workload is a two-level cache simulator. A supplied harness reads memory traces, invokes the participant’s simulator API, and compares statistics/correctness while ranking runtime.

Flow: generated or fixture trace → harness → submitted cache simulator → cache statistics/output.

Core paths:

• week-2/project/harness/main.cpp

• week-2/project/include/cache_sim.hpp

• week-2/project/CACHE_SPEC.md

The judge-oriented boundary is source submission of the simulator, built with fixed compiler flags rather than dynamically loaded strategy artifacts.

Week 3: Parallel Tick Aggregation

This stage moves to parallel reduction of a tick stream into fixed per-symbol integer aggregates. Deterministic, partition-independent results let the harness detect correctness failures caused by data races while comparing wall-clock performance.

Flow: tick input → worker partitioning/reduction → deterministic aggregate table → JSON/reference comparison.

Core paths:

• week-3/project/harness/main.cpp

• week-3/project/include/aggregate.hpp

• week-3/project/AGG_SPEC.md

Its architectural concerns are worker ownership, synchronization avoidance, cache-line contention, and optional CPU affinity.

Week 4: Lock-Free Processing Pipeline

Week 4 composes producer and consumer stages around a participant-built SPSC ring buffer. The producer decodes a binary feed into ticks; the consumer executes the unchanged Week 1 strategy and emits orders. In-order delivery preserves deterministic strategy output despite concurrent execution.

Core paths:

• week-4/project/harness/main.cpp

• week-4/project/include/pipeline.hpp

• week-4/project/PIPELINE_SPEC.md

The key boundary is cross-thread handoff: atomics and acquire/release publication replace mutexes, while the strategy remains a single-consumer pure sequential stage.

Week 5: Network Gateway Capstone

The capstone exposes the pipeline to a connected loopback UDP feed. A gateway implementation owns nonblocking socket ingest and epoll readiness handling, decodes wire ticks, transfers them over the SPSC boundary to a pinned strategy thread, and returns acknowledgements to maintain lossless in-order flow.

Core paths:

• week-5/project/harness/main.cpp

• week-5/project/include/gateway.hpp

• week-5/project/GATEWAY_SPEC.md

End-to-end flow: UDP sender → kernel socket/epoll loop → decode → SPSC queue → strategy → order stream, with ACK-window feedback to the sender.

Build, Runtime, and Evaluation Boundaries

Every project uses CMake (week-N/project/CMakeLists.txt) and C++20 on Linux; concurrency challenges require pthread support. Linux-specific runtime mechanisms become material in later stages: scheduler affinity, atomics, UDP sockets, and epoll. Python generators produce fixture data, while plotting scripts visualize cache, scaling, or latency results; they are offline support rather than production dependencies.

Specifications are frozen per week, harnesses and hidden inputs are judge-owned, and participant-owned implementation files are the optimization surface. Performance ranking prioritizes correct deterministic output and latency/throughput, not trading profitability.