Each claim the Scan timing and real-time page makes, with the tests that
prove it in the last green CI run: 4 of 21 verified, 7 with no test yet.
The claims live in docs/claims/real-time.yaml.
Last green CI run 16 Oct 2026, 14:48 UTC on c7618d3 · all runtime claims
RT-001 partly verified
Lateness is kept per task, cumulative since start, as the time from a slot's due time to the scan actually starting; late counts scans that started more than the threshold after their slot.
where the docs say so · Asserted on the parts: lateUs measures start minus a given slot, the tracker counts late scans beyond the threshold and accumulates, and main and a task carry separate lateness blocks. Not asserted: that Run's scheduler hands the scan its slot's due time (no test reads lateness from Run; TestLatenessUnderVirtualClock drives ScanTask, which passes no slot and takes the period form). "An early sample counts as a scan, not as late" dropped (not on the page).
- pass
TestLateTrackerCountsAndPercentiles in runtime - pass
TestLateUs in runtime - pass
TestLatenessUnderVirtualClock in runtime
RT-002 partly verified
overruns counts scans whose execution took longer than the period.
where the docs say so · Asserted on the tracker with a flag handed in; the detection of an over-period execution by the run loop is not asserted.
- pass
TestLateTrackerCountsAndPercentiles in runtime
RT-003 partly verified
The late threshold is the task's late-threshold, defaulting to a tenth of the period.
where the docs say so · The late-threshold manifest key is not parsed in a project-level test. The page example comment says the default for the 1 ms task is 100 µs, consistent with a tenth.
- pass
TestLateThresholdDefaults in runtime - pass
TestLatenessUnderVirtualClock in runtime
RT-004 partly verified
p50, p99 and p999 are bucket upper edges, about 3 percent above the true value (the bucket width is 1/32, 3.125 percent).
where the docs say so · The page (since #293) gives the 1/32 width, 3.125 %, which the tests bound: percentiles never below the true value and at most one bucket above it, on three samples; TestFineResolution checks the relative width of four buckets, not all of them. "Empty trackers report zeros" dropped (not on the page), with TestLateTrackerEmpty.
- pass
TestLateTrackerCountsAndPercentiles in runtime - pass
TestFineBucketsAreMonotonic in runtime - pass
TestFineResolution in runtime
RT-005 partly verified
The lateness histogram is 1-2-5 log-spaced from 1 µs to 100 ms.
where the docs say so · Bucket indexes pin the edges at 1, 2, 5, 1000 and 100000 µs and the count between them; the other edge values, and the bucketsUs list reported in the snapshot, are not listed.
- pass
TestCoarseIndex in runtime - pass
TestLateTrackerCountsAndPercentiles in runtime
RT-007 partly verified
The scan block reports scan time (lastMs, minMs/maxMs, a 2 ms histogram, the phase bar) separately from lateness.
where the docs say so · lastMs, min/max and a 15-bucket histogram are asserted. The 2 ms bucket width and the phase-bar fields (beyond ExecUs > 0) are not. "Per task" dropped (the page keeps lateness, not scan time, per task).
- pass
TestScanStatsDiagnostics in runtime - pass
TestFrameCarriesScanDiagnostics in server
The loop keeps an absolute schedule so lateness never accumulates, and a loop more than a whole period behind skips the lost slots and reports them as missed instead of firing a burst of catch-up scans.
where the docs say so · In virtual time, with every wake 50 µs late and every scan 200 µs long, each scan starts exactly 50 µs after its slot on the start + n·period grid, and a five-period stall reports four missed slots and fires no burst.
- pass
TestRunLoopHoldsScheduleAndCountsMissed in runtime
RT-010 partly verified
On Linux the sleep is the kernel's absolute sleep (clock_nanosleep) on a thread of the task's own with reduced timer slack, avoiding the one-millisecond rounding of a Go timer.
where the docs say so · Checks the wake-up lands within 10 ms of the deadline; the sub-millisecond precision and timer-slack setting are not asserted (hardware dependent).
- pass
TestSleepUntilLandsOnDeadline in runtime
Task isolation: each scan copies its external tags in, executes privately, and commits what changed as one unit, so a reader never sees a scan half-done.
where the docs say so · The equal-value-write generation rule dropped from the claim (not on the page).
- pass
TestScanViewSnapshotAndCommit in runtime - pass
TestScanCommitsAreAtomic in runtime
Tasks run concurrently, and a fast task never waits behind a slow one.
where the docs say so · TestTasksRunConcurrently stalls the main scan in its driver read and the aux task keeps scanning under Run; TestFastTaskDoesNotWaitForSlowTask parks the main program mid-scan and the fast task scans and commits.
- pass
TestFastTaskDoesNotWaitForSlowTask in runtime - pass
TestTasksRunConcurrently in runtime
Two tasks writing the same tag resolve by commit order, last commit wins.
where the docs say so
- pass
TestScanViewSnapshotAndCommit in runtime
The VM makes no allocation per builtin call, user-function call or function-block step, so the scan loop gives the garbage collector no work.
where the docs say so · Verified by allocation benchmarks (b.ReportAllocs) that do not assert a zero count; no AllocsPerRun test.
A 1 ms task alone runs every scan with p99 lateness around 30 to 55 µs on a busy desktop with a stock kernel, and a 20 ms task beside it changes nothing it can see.
where the docs say so · Hardware-dependent latency figure measured with tools/jitter and docs/design/realtime.md; not CI-testable.
RT-016 partly verified
A task's cpu setting pins its thread to that core (Linux).
where the docs say so · Pinning is asserted on applySched (skips when only one CPU is allowed), and Run is shown to apply a CPU list from Options. The cpu: manifest key is not parsed in a project-level test. The nonexistent-CPU failure is not a page claim.
- pass
TestApplySchedAffinity in runtime - pass
TestRunReportsSched in runtime
RT-017 partly verified
A task's priority requests SCHED_FIFO at that priority (1 to 99).
where the docs say so · The refusal path and the 1-99 range check are asserted, but the whole test skips where SCHED_FIFO is granted, and a successful SCHED_FIFO grant is never asserted. The priority: manifest key is not parsed in a project-level test.
- pass
TestApplySchedFIFORefusalIsExplicit in runtime
RT-018 partly verified
A refused SCHED_FIFO or pin request is loud: the error names the fix, the refusal shows on the task's row (REFUSED), and the task runs at normal priority.
where the docs say so · Asserted: a SCHED_FIFO refusal names CAP_SYS_NICE, setcap and ulimit -r, and Run records either applied or the refusal in the task's sched stats (RT-019 merged here). Not asserted: the REFUSED dashboard label (a Svelte component), the logged error line, the wording of a pin refusal, and that the refused task keeps scanning.
- pass
TestApplySchedFIFORefusalIsExplicit in runtime - pass
TestRunReportsSched in runtime
SCHED_FIFO priority reduces p99 lateness from 55 µs to 20 µs and the worst case from 2.3 ms to 0.3 ms on the busy desktop; cpu alone worsens p99 to 300 to 400 µs.
where the docs say so · Hardware and load dependent measurement; not CI-testable.
A task that continuously overruns its period under the kernel RT throttle (95 percent of every second) shows as missed slots.
where the docs say so · Depends on kernel sched_rt_runtime_us; not CI-testable. Missed-slot counting itself is covered by TestRunLoopHoldsScheduleAndCountsMissed.
Kernel boot parameters (isolcpus, nohz_full, rcu_nocbs, irqaffinity) keep a pinned core quiet.
where the docs say so · Kernel configuration guidance, not a runtime behaviour a test can falsify.
With GOGC=off and a memory limit, GC collections drop from 448 a minute with a 2.1 ms worst pause to 12 with an 82 µs worst pause under 50 MB/s of allocation elsewhere.
where the docs say so · Hardware and workload dependent measurement; not CI-testable.
tools/jitter runs a mixed resource (1 ms loopback I/O task, 10 ms task, slow task, allocation-heavy task) on the real scheduler and writes a report with machine, kernel, Go version and settings beside the numbers.
where the docs say so · No test for the jitter tool.
