#299 -- REMAINING CALLEES TRACED. The path is now read end to end, and there is a SECOND candidate that fits the reported numbers far better than the SQLite one. Source only, nothing run. == THE FOUR I OWED YOU, CLEARED == perch::identity_dir() pure path join, spt_home().join("identity"). NO I/O AT ALL. VisibilityStore::load() one read_to_string + serde over one file; absent/corrupt degrade to defaults. SubnetStore::load() same shape, one file. resource_projection() spt-net/src/net/registry.rs:590. PURE IN-MEMORY transformation over an ALREADY-LOADED SubnetRegistry -- iterates endpoint_ids and instances, fills node labels from an in-memory BTreeMap, pushes rows. No I/O, no lock, no deadline. "Cleared" here means structurally: none of these contains a wait, a lock or a deadline. It does not mean they are fast, and I am not repeating that error -- a single read_to_string is still subject to filesystem latency I have not measured. == THE STAGE I HAD NOT LOOKED AT IS A NETWORK FANOUT WITH A TEN-SECOND CEILING == Following d5fe86c3's own stage list to its last unread entry -- "each presence probe stage" -- led here, in the HUMAN path at cli.rs:6822: // [impl->REQ-UNLISTED-PRESENCE-PROBE] the probes fan out here, BEFORE the ... let unlisted_rows = probe_unlisted(gather_unlisted(...)) fn probe_unlisted(rows) -> Vec cli.rs:7019 "The real fan-out: each row's node is ASKED OVER THE WIRE, in parallel." -> wansend::probe_presence(id, node, &asker, ...) per row that HAS a node fn probe_unlisted_with(...) cli.rs:6981 probe_all_with(&worklist, PRESENCE_PROBE_CEILING, MAX_INFLIGHT, Presence::Unknown, probe) const PRESENCE_PROBE_CEILING: Duration = Duration::from_secs(10); cli.rs:6968 const MAX_INFLIGHT: usize = 16; cli.rs:14205 The constants carry their own doc comments, and they are explicit about the shape: the ceiling is "per probe: one wedged node costs one ceiling, never the batch", and the fan-out is "wall-time approximately ONE ceiling when items.len() <= max_inflight, else ceil(k/max_inflight) ceilings". So for a worklist of 16 or fewer nodes, THE WHOLE VERB'S FLOOR UNDER A SILENT PEER IS ONE TEN-SECOND CEILING. DEADLINE AND LOCK OWNERSHIP, answering your original question properly this time: network deadline PRESENCE_PROBE_CEILING, cli.rs:6968, owned by the CLI, 10 s, no env override found; concurrency bounded by MAX_INFLIGHT = 16 (cli.rs:14205) local lock SQLite on /.registry, budget registry_busy_timeout() (spt-store/db.rs, 5 s production default, SPT_REGISTRY_BUSY_TIMEOUT_MS override), plus the WAL-switch retry loop metadata cost the per-perch read_info / ready-file / pid-probe legs That is the three-way distinction the acceptance criterion demands, and the first category now has a named owner. == WHY THIS FITS THE REPORTED NUMBERS, INCLUDING THE PART THAT LOOKS LIKE IT REFUTES IT == Reported: 3822 / 10120 / 10105 ms, each rc=0, each BYTE-IDENTICAL 2497-byte complete output. 10120 and 10105 sit 120 and 105 ms above a 10 000 ms ceiling, and within 15 ms of each other. That is the signature of a bound being reached, not of work being done. THE APPARENT REFUTATION, which I want on the record because I nearly used it to kill the candidate: a blown ceiling yields Presence::Unknown, and render_unlisted (cli.rs:7050) renders presence via r.presence.map(|p| p.token()) -- so Unknown has its OWN TOKEN, distinct from a present or absent answer. If a probe had blown its ceiling in the slow runs but answered in the fast one, the bytes WOULD have differed. They did not. IT RESOLVES, AND THE RESOLUTION IS THE INTERESTING PART: an UNREACHABLE node yields Unknown whether it fails FAST or blows the ceiling. A refused connection and a ten-second silence render the same token. So byte-identical output across a 3.8 s run and a 10.1 s run is exactly what you would see from a peer that was refused quickly once and black-holed twice -- same rendered answer, six seconds of difference in the wall. That also supplies the mechanism behind the reporter's own note that UNREACHABLE PEERS ARE CORRELATED: the correlation would be causal through the probe ceiling, while remaining invisible in the output. STILL A CANDIDATE, NOT THE CAUSE. I have not established that the observed wait is here. What would settle it is already built: d5fe86c3's ROSTER_WAIT names each presence probe stage separately and records whether a stage hit its budget or its producer completed, and it distinguishes an outer observation cutoff from producer completion. Running it attributes the wall; nothing new needs designing, and I am not asking to run it while hertz holds the window. I have ALSO not established the worklist size on the reporter's box, and it matters: k <= 16 means one ceiling, k > 16 means ceil(k/16) ceilings. At 10.1 s observed, one ceiling is the consistent reading. == CORRECTIONS CARRIED == Your 1.9 s arithmetic is right and my "~1 s" was the code comment, not a measurement -- 200 sleeps of 5 to 14 ms is about 1.9 s BEFORE any SQL execution cost. I should have used my own arithmetic rather than quoting a comment as a bound. Recorded as you directed: d5fe86c3 is INSTRUMENTATION, not a diagnosed fix. #230's request-specific work is 38e0e723 plus b1c665eb and its retained acceptance receipts. Nothing to reconstruct. RELATIVE STANDING OF THE TWO CANDIDATES, stated plainly so the next reader does not have to weigh them from scratch: the presence-probe ceiling explains the plateau's VALUE (10 s), its TIGHTNESS (15 ms apart), the byte-identical output, the rc=0, the local reproduction and the reporter's unreachable-peer correlation. The SQLite per-perch open explains a cost that GROWS with perch count and is consistent with bimodality, but nothing in it predicts 10.1 s specifically. Both stay open; they are not exclusive, and the instrument attributes both. == NEXT == Proceeding to #49/#267 failed-fix archaeology now, source and history only.