[Japabu]

Records only: a fresh scoreboard of ToyOS against Linux on both benches at main ad5db5a65. It measures and records; it fixes nothing and changes no manual page.

What it reads

Per bench, one reserved session: four osbench boots interleaved with five Linux osbench all runs (L1 T1 L2 T2 L3 T3 L4 T4 L5). A row is behind or ahead when the committed compare's exact two-sided Mann-Whitney test gives p under 0.05 (at four against five: no inversion, or one; every row behind has none), at parity when unresolved with medians within 1.10, unresolved otherwise.

bench	judged	behind	ahead	at parity	unresolved
T14	134	70	52	7	5
AMD bench	133	35	76	8	14

The largest gaps, in the hotness order the home record states (its own, since the tree declares no hot rows; its first tier stands on proxies for build throughput and application launch):

• Process spawn and the all-CPU build. proc.spawn_wait.large 147x on the T14 and 45x on the AMD bench (8.1 and 12.6 ms against 55 and 279 µs); work.build_shaped at every CPU 2.22x and 2.57x; the other T14 process rows 1.38x to 2.17x. The spawn rows are ad5db5a's; A child's arguments and environment are memory its parent lays out #1200 has since changed how a child's arguments are laid out, unmeasured here.
• File calls through a file server. T14 fs.disk metadata 5x to 44x and fs.mem 6x to 35x; a 4 KiB write at an offset 31x on DATA and 14.6x in memory; 4 KiB sequential writes 3.5x and 8.2x. On the AMD bench the same rows are 1.7x to 19x behind Linux's two TSC-timed runs.
• Switch and wake on the T14: time.yield 3.41x, pingpong.futex.same_cpu 1.78x, wake.onto_busy 1.74x (1.80x on the AMD bench, 2.16x against its TSC runs), ipc.reqrep.8 1.71x, pingpong.pipe.cross_core 1.56x, time.now 1.47x.
• Timed wakes, against Linux without its 50 µs timer slack (exploratory: the rule was set against the default rows, where all eight timer rows a bench count ahead): T14 time.sleep_late.100us 2.85x, wake.periodic.loaded 1.53x, wake.periodic.idle 1.18x; AMD time.timer_1ms.late 2.03x. Later scoreboards judge against the slack-free rows.
• Durable writes. The T14 was in its slow mode in four boots of four (6 to 7 ms against 1 ms). The AMD bench's persist.seq_write_fsync is 2.01x behind (260 against 523 MB/s), its 4 KiB durable writes ahead.

Every row behind, ranked, with the one record that owns it, is in issues/toyos-against-linux-on-both-benches-the-scoreboard.md.

Records

• The home record, renamed from no-published-run-compares-toyos-with-linux-on-one-machine with its citations: the rule, the session's rows behind, and the gaps.
• New, one per gap that had no owner: a clock read on the T14; a wake onto a busy CPU; the T14's storm drains; the one-group all-CPU total (a finding); the timed wakes against slack-free Linux.
• Renamed to what their tables read, with their stale sentences corrected: the yield record (measured now, a defect), the memory-filesystem record (up to 35x) and the spawn record (up to 147x).
• Given this session's figures: the file-server, small-message, ping-pong, memcpy, user-memory, shootdown and created-fsynced-unlinked records, the T14 durable-write record (four slow boots of four), and the speed track (the AMD bench's matmul has read 1.03x twice).
• pingpong.futex.cross_core held no park in three of the T14's four boots; where it did it reads 1.37x behind, as on 2026-10-28. The ping-pong record's exit now asks the row for a park count per round.
• The AMD bench's persist.seq_write_fsync is owned by the record open PR A reserved write's bytes go to the device at once, at the session's depth #1216 adds, named as such.

Evidence and checks

• Evidence: https://github.com/ToyOSOrg/evidence/tree/784d15e532d89aaa178162a1546024af1fc851df (every run's osbench lines, both compare tables, the scoreboards and their -r2 successors, the slack-free timer tables, the judge logs, the request with the rule set before the runs, the method). Its README states the session and, appended, its corrections after review r1.
• All ten Linux runs exited 0 with all 16 groups; all eight boots ran all 16 groups, and the judge's osbench and clock_holds_over_minutes rows pass for each. boot:benchcase also selects two I219 rows of another boot sharing the label, so those judge logs end exit 1 on those two alone; clock_holds_over_minutes by name exits 0 for all eight.
• Host: the three gates a records change can move (no_tracked_file_identifies_a_machine_or_its_network, every_pending_exception_cites_an_issue_that_exists, every_committed_binary_file_is_declared), exit 0 at the head's tree. The full host suite was not run: nothing but issues/ changed.

Limits

• The host's network was down from about 09:00 to 11:35 UTC. The T14's fourth boot ran in sequence and was read back late; the AMD bench's fourth boot was repeated at 11:39; each bench's L5 followed. The compare tables list every run.
• The AMD bench's Linux timed three of its five runs through the HPET. The verdicts barely depend on it: every row behind is worse than both TSC runs in every boot, and 74 of the 76 ahead beat both. The ratios do: the HPET runs add the instrument's 1.2 µs a timestamp to Linux, so the home table is ordered by the ratio against the two TSC runs, exploratory at two. A clean reading needs five TSC-timed Linux runs.
• "76 ahead" is not 76 faster paths: Linux as installed pays system-call mitigations ToyOS has none of, and after 23 of those rows, all block-and-wake shapes, Linux's reporting thread read its clock at 1.37 to 1.9 GHz against ToyOS's 4.2 to 4.3 GHz.
• One boot set per bench is a measured comparison of one revision. No figure here is a bound a test asserts.
• Energy (both benches) and the T14's LAN chain are staged and not yet run. No osbench row compares graphics, audio, application launch to a usable state, a build of compiler work or battery life with Linux; the home record lists these gaps.
• The first durable write after the drive idles, reported about 1.1 ms behind by other work, is not something an osbench row measures; this session neither confirms nor contradicts it.

Corrected after review r1

The first description said #1215 rewrites the T14 durable-write record (it added a pointer and a finding; this PR now adds the four slow boots there), that the AMD bench's "ahead" count flatters ToyOS (the count stands; the ratios were understated), and counted the timer rows ahead without the slack-free reading. The evidence README's "1.6% resolve by chance" is 3.2%, and its "bimodal per boot" for the futex row was wrong; both are corrected by an appended section.

🤖 Generated with Claude Code

[Japabu]

Review r1 of #1217 at 82976d7 (base ad5db5a; main is 422915e)

SEND BACK. The arithmetic is right and the evidence is clean; four things in the records are not.

Assessment

Records only: 14 files under issues/, +536/−23, no production or test code. It merges cleanly onto main; none of its files were touched by #1200, #1210, #1212, #1213 or #1215. Putting the ranking in the existing home record and one table per owning record is the right shape. I recomputed everything from the raw run files with my own parser and exact test, not the evidence's script.

What I verified

• Counts. T14 70 / 52 / 7 / 5 and AMD 35 / 76 / 8 / 15 of 134, reproduced exactly. All 70 and all 35 behind rows are in the home tables, with no extras.
• Cells. 281 table cells across the changed records match the raw medians and ranges. 18 ratios differ by 0.01 because they were divided from rounded medians (pipe.throughput.64 is 1.44x, not 1.45x). Not material.
• Requested rows. All reproduce, direction handled correctly for rates:

row	T14	AMD
proc.spawn_wait.large	8,072,387 / 54,731 ns, 147.5x behind	12,586,708 / 278,643 ns, 45.2x behind
fs.disk.fstat	9,532 / 215 ns, 44.3x	8,936 / 1,885 ns, 4.74x (18.6x against the TSC runs)
fs.mem.fstat	7,560 / 213 ns, 35.5x	9,117 / 1,886 ns, 4.83x (18.8x)
fs.disk.write_4k_at	22,421 / 721 ns, 31.1x	26,440 / 2,933 ns, 9.01x (13.3x)
work.build_shaped all-CPU	2.22x behind	2.57x behind
work.build_shaped.j1	0.68x, ahead	0.54x, ahead
time.yield	651,614 / 190,906 ps, 3.41x	1.13x
wake.onto_busy	4,444 / 2,553 ns, 1.74x	1.80x
persist.seq_write_fsync	182 / 590 MB/s, 3.24x	260 / 523 MB/s, 2.01x
ahead: syscall.null	68 / 92 ns	49 / 159 ns
parity: ipc.reqrep.4096 (T14)	0.92x, p 0.90
unresolved: pingpong.pipe.same_cpu (T14)	1.31x, p 0.73

• Like with like. proc.spawn_wait.large is the same generated ELF on both (33,558,528 bytes: a 32 MiB read-only segment the program never touches), spawned by Command from each system's memory filesystem. Linux reads 54.7 µs against 52.4 µs for tiny; ToyOS reads the image whole. File rows: every judged row names one medium on both sides (memory or nvme). ToyOS-only (fs.*.direct.*, tail.diag), Linux-only (fair.session.*, .slack1ns) and unsupported or unmeasured rows (net.*, nvme.read.*, crunch.all.*) are excluded, not counted. One exception is under Suggestions (crunch.single.parse).
• Evidence. All 18 run files hold 15 completed groups (the 16th, identity, is dropped by the mask). Both chain logs show rc=0 for all ten Linux runs. All eight judge logs show PASS osbench and PASS clock_holds_over_minutes and exit 1 on the two I219 rows alone; all eight clock logs exit 0. No vendor, model, firmware, host name, disk ID, address or user path anywhere: CPU model reads <bench>-bench-cpu, disk model masked.
• Earlier scoreboard. The new records' claims about 2026-10-28 (time.now 19.8 against 14.3 ns; wake.onto_busy 1.72x and 1.91x; fair.shared the same shape) match that evidence branch.

BLOCKERS

1. issues/no-published-run-compares-toyos-with-linux-on-one-machine.md:103, :250 — the record cites the manual twice ("what the manual's performance page names", "which the manual's performance page names"). Root CLAUDE.md: no issue record cites it. State tier 0 in the record's own words.

2. Same file, :108-110 and the T14 and AMD tables — eight timer rows per bench are counted "ahead" against a Linux that pads each sleep by 50 µs, and four of them are behind Linux without the padding. tests/guest/osbench/src/time.rs:17-18 says why the .slack1ns variants exist: "an ordinary Linux sleep is padded by up to the thread's timer slack, 50 µs by default. ToyOS has none." The evidence holds those slack-free Linux runs. By the same test:

row	ToyOS	Linux, slack 1 ns		counted as
T14 time.sleep_late.100us	5,210 ns	1,827 ns	2.85x behind, p 0.016	ahead, 0.10x
T14 wake.periodic.loaded	3,624 ns	2,373 ns	1.53x behind, p 0.016	ahead, 0.07x
T14 wake.periodic.idle	20,806 ns	17,667 ns	1.18x behind, p 0.016	ahead, 0.31x
AMD time.timer_1ms.late	49,110 ns	24,250 ns (11,126 and 11,601 in the TSC runs)	2.03x behind, p 0.016	ahead, 0.66x

These are wake-path costs (the two wake.periodic rows are tier 1 by the scoreboard's own table), and they are unranked and have no record. They also moved unseen since 2026-10-28: T14 wake.periodic.loaded 3,024 → 3,624 ns, time.sleep_late.100us 4,387 → 5,210 ns. The rule was set before the runs against the default-slack rows, so this reading is exploratory in the same sense as the TSC column. It still has to be stated, and the four rows need an owner.

3. issues/a-two-thread-ping-pong-costs-toyos-up-to-twice-linuxs-on-the-t14.md:57-60 and the home record :188-190 — "bimodal per boot" is wrong, and "which mode is a round trip through a park is not established" is contradicted by the record's own earlier table.

   • Boot 3 mixed both modes inside one run: p50 257, p90 4,578, mean 1,188 ns. The AMD's fourth boot did too (min 150, p50 4,629, mean 2,911 ns). A run's p50 is not this row's value.
   • The same record's 2026-10-28 table reads the T14 at 4,574 ns in all four boots (4,566, 4,553, 4,668, 4,582), 1.37x Linux's, resolved. This session's fourth boot read 4,573 ns. That is the parked round trip.
   • The fast mode cannot contain a park. A round trip of 213 to 257 ns holds two futex_wake calls, yet the same boots' time.yield alone costs 652 ns and the same-CPU round trip 4,091 ns. The kernel's wait returns at once when the word has already moved (kernel/src/scheduler.rs:257), so the likely reading is that neither thread sleeps. That is my inference from the timings; nothing in the row counts parks.
   • So on the T14 the row does not measure what it means in three boots, and where it did it reads 1.37x behind, as before. Say that. A park count per round in the row would settle it.

4. Two records' headings are refuted by the tables this branch adds to them, and each now contradicts itself. issues/README.md makes a slug a claim, renamed when refuted; the branch did that for the yield record. Each slug is cited only by the home record.

   • issues/a-tmpfs-metadata-call-costs-toyos-up-to-six-times-linuxs.md:7 says "up to six times"; the new table reads 35.5x (fstat), 16.4x, 14.6x. :83 still says "these eight rows" while :80-82 appends that the exit covers all nineteen. Edit the exit instead.
   • issues/spawning-a-process-costs-toyos-up-to-four-times-linuxs-on-the-t14.md:7 says "up to four times ... on the T14"; the new table reads 147x there and 45x on the AMD bench. :58-65 still says a large spawn "snapshots" a /tmp file by taking page references, while :91-93 says the image is now a served file read through the pager.

SUGGESTIONS

• The AMD bench (home record :192-195). Verified: every group of runs 1 to 3 states clocksource=hpet, runs 4 and 5 tsc; time.now 1,213 ns against 22.6 ns. In 87 of 133 rows every HPET run is worse than every TSC run.
  • The verdicts barely depend on it: all 35 behind rows are worse than both TSC runs in every boot, and 74 of the 76 ahead rows are better than both. Only fair.shared.total (1.25x) and fs.mem.read_4k_at (1.04x) would change sides. So the counts can stand against all five, labelled as they are.
  • The ratios cannot headline. For a per-operation row the HPET runs add osbench's own 1.2 µs timestamp to Linux's figure, which is the instrument and not Linux's path (fs.*.seek: 0.14x against five, 0.95x against the TSC runs). The AMD table is sorted by the diluted ratio, which puts write_4k_at (13.3x) above fstat (18.8x). Sort by the TSC column.
  • A clean reading needs five Linux runs that all state clocksource=tsc, interleaved as now. Each ToyOS boot already reboots Linux, so check the clocksource before each run and reboot until it is the TSC, logging the boots passed over. Not tsc=reliable, which the osbench README rules out.
  • Two more things "Linux as installed" carries there, neither mentioned. Its system-call path pays mitigations ToyOS does not have (syscall.null 159 against 49 ns; the run lines list retpolines, IBPB, STIBP and Safe RET; issues/indirect-branches-and-returns-run-without-thunks.md and issues/no-entry-or-switch-clears-the-bhb-fills-the-rsb-or-issues-an-ibpb.md are open). And after 22 of the 76 ahead rows, all block-and-wake shapes, Linux's reporting CPU read 1.37 to 1.9 GHz against ToyOS's 4.2 to 4.3 GHz. That probe reads the reporting thread's CPU, so that the measured threads ran slow is an inference; the README's labelled performance-governor experiment would settle it. A sentence on each keeps "76 ahead" from being read as 76 faster paths.
• The rule's wording (home record :99-100). "Every boot read worse than every Linux run" is true of all 105 behind rows. It is not what p under 0.05 means at four against five: one inversion gives 4/126 = 0.032. Three ahead rows resolve that way or on a tie (T14 tail.stolen.10s; AMD persist.create_fsync_unlink, fs.disk.pread_4k).
• Owners. Nine T14 rows and seven AMD rows list two records; say which owns the gap against Linux. The persist.seq_write_fsync cells (:177, :229) give a bare slug and "none on main, another assignment holds the row": that record is issues/a-sequential-durable-write-on-data-runs-at-about-half-linuxs.md in A reserved write's bytes go to the device at once, at the session's depth #1216, and whichever lands second should name it. :233 gives crunch.single.matmul (1.03x) to a track that says the AMD bench has no such gap.
• Owning records left without this session's figure. The T14 durable-write record: osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215 added a three-line pointer, not a rewrite, so four slow boots of four at ad5db5a are recorded only in the home record, and they bear on the count main's new idle finding is collecting. a-created-fsynced-and-unlinked-file-... says the AMD bench is 8% dearer; this session reads it ahead. a-tlb-shootdown-... still carries the 2026-10-28 munmap figures.
• Tier 0 and the gaps (:246-256). The tiers are labelled as the scoreboard's own, in the record and the PR. Tier 0 holds proxies: work.build_shaped compresses files, the spawn rows end at exit; the gap list says so, the tier line does not. The same page also names battery life, which is absent from tier 0 (energy is staged and its units have no direction). Gaps to add: boot to a usable state (both systems report it as conditions, not rows); the six fair.* share rows, which have no direction and so no verdict; Linux's nvme.read.* was unmeasured too (not run as root); the all-core crunch is unmeasured on ToyOS, not unsupported.
• crunch.single.parse on the AMD bench is among the 134 with two Linux runs of five (three stopped at the package limit). It cannot resolve at two against four.
• The home record's own heading and exit (:7, :258) say no published run exists and ask for one. That predates this branch, but this branch makes the record the scoreboard's home.

For the orchestrator (PR description)

• "The T14 durable-write record, which osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215 rewrites": osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215 added three lines and a separate finding.
• "The AMD bench's 'ahead' count flatters ToyOS": the evidence says otherwise, 74 of 76 beat both TSC runs in every boot. What the HPET understates is the ratios behind, as the description goes on to say.
• The evidence README's "about 1.6% of rows resolve by chance" is 3.2% at four against five (4/126), and its "bimodal per boot" for the futex row is blocker 3.
• The spawn rows are ad5db5a's; A child's arguments and environment are memory its parent lays out #1200 changed how a child's arguments are laid out after it, unmeasured here.

[Japabu]

Review r2 of #1217 at 0c1cb24 (base 422915e)

LAND. The four blockers of r1 are resolved and every suggestion taken checks out against the raw run files. One sentence of the home record is inexact; it moves no verdict, rank, count or owner, so it is a suggestion.

Assessment

Records only: 25 files under issues/, +978/−249 against main (three renames read as delete and add); this round is +360/−144 in 12 files. The rebased first commit is identical to r1's 82976d7 (git range-diff), so only 0c1cb24 is new. One home record with the rule and the ranking, one owning record a row, and the per-record tables is still the right shape. The evidence commit 784d15e is on the append-only pr-1217 branch with d44ebda as its parent; the run files are unchanged.

I recomputed from the raw linux-*.txt and toyos-*.txt with my own parser and exact test, not method/slack.py.

Blockers of r1

1. Manual citations: resolved. No changed record names the manual, a page of it or docs/. Tier 0 (issues/toyos-against-linux-on-both-benches-the-scoreboard.md:121-125) names build throughput and application launch as proxies and why each is one, and battery life as present in the requirements and absent from the rows.

2. Timer rows: resolved. Both readings are stated per bench in the home record (:224-241, :316-333) and in the new issues/a-timed-wake-is-later-than-linuxs-without-its-timer-slack.md, which is the one owner of all four. The rule for later scoreboards is at :113-117 and in the exit. Recomputed:

row	ToyOS boots (p50 ns)	Linux .slack1ns runs	medians	ratio	p	pairs with ToyOS not later
T14 time.sleep_late.100us	5,238 5,182 4,907 5,270	1,809 1,831 1,827 1,827 1,821	5,210 / 1,827	2.85x	0.016	0 of 20
T14 wake.periodic.loaded	3,633 3,629 3,618 3,612	2,355 2,379 2,449 2,366 2,373	3,624 / 2,373	1.53x	0.016	0 of 20
T14 wake.periodic.idle	20,910 20,769 20,844 20,703	17,684 19,433 17,667 17,559 17,600	20,806 / 17,667	1.18x	0.016	0 of 20
AMD time.timer_1ms.late	49,188 49,721 48,827 49,033	24,287 24,250 24,325 11,126 11,601	49,110 / 24,250	2.03x	0.016	0 of 20

The AMD row against its two TSC runs is 49,110 / 11,364 = 4.32x. The other twelve cells of the two slack tables match too, as do "all eight count ahead against the default rows" on each bench (p 0.016 each) and the 2026-10-28 figures the record cites (4,387, 3,024 and 17,815 ns).

3. pingpong.futex.cross_core: resolved. The ping-pong record and the home record (:213-222) now say three T14 boots did not measure a parked round trip, give the one that did as 1.37x behind as on 2026-10-28, and label the no-sleep reading an inference. Every figure reproduces (p50 257, 250, 257, 4,573; minimum 213 to 215; boot 3 p90 4,578, mean 1,188; AMD boot 4 minimum 150, p50 4,629, mean 2,911; 4,573 / 3,346 = 1.37). The exit asks pingpong.futex.* for the parks of each round.

4. Headings and stale sentences: resolved. a-memory-filesystem-call-costs-toyos-up-to-35-times-linuxs (35.49x) and spawning-a-process-costs-toyos-up-to-147-times-linuxs (147.49x) match their tables. The earlier tables are marked as the kernel-/tmp era's, the "snapshot" paragraph is past tense with the served-image account beside it, and the memory record's exit names every fs.mem row of the second table. git grep at the head finds none of the four old slugs anywhere in the tree, and every issues/*.md path the changed records cite exists. The home record's seven citations in four records moved; its heading and exit describe a scoreboard, not an absent one.

Suggestions taken, checked

• AMD table. All 35 TSC ratios reproduce and the table is in descending TSC order within each tier. Every row behind is worse than both TSC runs in every boot; of the 76 ahead, 74 beat both in every boot, the exceptions being exactly fs.disk.pread_4k and persist.create_fsync_unlink. "A clean reading needs" is stated.
• Counts. T14 70 / 52 / 7 / 5 of 134 and AMD 35 / 76 / 8 / 14 of 133 reproduce, with crunch.single.parse (two Linux runs, p 0.133) the one row without a verdict. The home record, the PR table, the second commit's message, the evidence README's appended section and amd/scoreboard-r2.md agree. No record carries the old 15.
• The rule. "No inversion (2/126) or one (4/126)" and "about 3%" are right at four against five.
• One owner a row. No cell of either table names two records. :293 names A reserved write's bytes go to the device at once, at the session's depth #1216's record as a bare slug with "the record open PR A reserved write's bytes go to the device at once, at the session's depth #1216 adds"; A reserved write's bytes go to the device at once, at the session's depth #1216 is open and does add issues/a-sequential-durable-write-on-data-runs-at-about-half-linuxs.md. Whichever lands second turns it into a path.
• Records given the session's figures. All reproduce: the T14 durable-write table (twenty per-boot cells, five Linux ranges, clean fsync 7,365 to 7,570 ns), created-fsynced-unlinked (AMD 2.83, 3.01, 2.86, 2.54 against 3.01 to 3.37 ms, one inversion, so ahead), shootdown (1.12x, 1.47x, mprotect ahead; AMD ahead on all three), and the speed track's matmul (1.03x resolved on both dates, settled clocks 4,265 to 4,304 MHz). The durable-write record is consistent with what osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215 landed: those boots ran no write_4k_fsync_after_idle, "Those boots had no idle row" says so, and osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215's pointer to the idle finding follows it untouched.
• Evidence. The eight files 784d15e adds or changes carry no address, serial, host name, user path or vendor or model string; a scan of the whole tree at that commit finds only mask.sh's own patterns.

SUGGESTIONS

• issues/toyos-against-linux-on-both-benches-the-scoreboard.md:310-312 — "where ToyOS's read 4.2 to 4.3 GHz" is true of 19 of the 23. Reconciling the count: 23 is right for "the median of Linux's five mhz readings is under 2 GHz" (1,369 to 1,910 MHz). After four of those rows ToyOS's reporting thread read low too, in some boots:

row	ToyOS mhz, four boots
mem.malloc_churn.1048576.t1	4,167 1,874 1,874 1,863
time.sleep_late.1ms	1,397 4,291 4,291 1,397
wake.periodic.idle	1,397 10,506 1,397 4,291
mem.malloc_churn.16.t1	4,216 1,874 2,390 4,216

r1's 22 is the 23 less the first of these, where ToyOS's median was under 2 GHz as well. That is my reconstruction from the data; r1's script is not kept. The "4.2 to 4.3 GHz" was r1's wording and was loose there too. Suggested: "after 23 of the 76 ... 1.37 to 1.9 GHz; after 19 of those ToyOS's read 4.2 to 4.3 GHz, and after the other four ToyOS's own reading was low in some boots". Also "in the median run" is the median of the five runs' readings; the run that supplied the median p50 gives 21 rows. The same sentence is in the PR body and the evidence README's appended section.

• Same file, :298-300. "Not behind by the rule, yet behind both TSC runs" lists fair.shared.total alone. fs.mem.read_4k_at is also slower than both TSC runs in every boot (1,442 to 1,483 against 1,403 and 1,413 ns, 1.04x), and two parity rows by 1 to 2%. Either add it or say the list is of rows more than 1.10 apart.
• Same file, :110. "A row fewer than four runs of either system measured has no verdict" sits under "set before the runs", but session/request.txt says three against five still resolves. No row here has exactly three, so nothing changes.
• issues/a-timed-wake-is-later-than-linuxs-without-its-timer-slack.md points at no neighbour. issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md reads the 1 ms timer's lateness on the T14, and issues/idle-cpus-enter-the-c-states-cst-names.md and issues/a-cpu-leaving-hlt-runs-its-first-microseconds-slow-under-c1e.md both measure by the time.sleep_late rows. A pointer saves the next reader the search.
• issues/the-t14s-slow-durable-writes-ended-during-80-s-of-idle-in-four-boots-of-four.md counts one boot of seven leaving the slow mode unprompted. This session adds four that began slow, ran no idle row and stayed slow. That record is assigned elsewhere and not in this branch; its holder may want the figure.

For the orchestrator

• The PR body matches the final change apart from the 4.2 to 4.3 GHz clause above. It says the futex row "held no park" where the records label that an inference from the timings.
• The first commit's message still says osbench's disk groups as a metal row, and the forced journal write recorded as measured and declined #1215 rewrites the durable-write record and counts 15 unresolved on the AMD bench; the second commit and the body correct both. It matters only if the landing keeps commit messages.
• The three host gates the body reports as exit 0 have no log in the evidence. By inspection the renames cannot fail them: no old slug remains in the tree, the diff adds no identifier shape and no binary file. I ran nothing.

LAND