The clock estimate reports −184515 ppm drift and ±36.77 ms after a settled burst

[liversedge]

The measurement

From make test-device against a live PinPointStudio, 27 August:

DEVICE-RUN agreement=± 36.77 ms  drift=-184515 ppm, filtered

⛔ −184515 ppm is −18%. A real crystal is tens of ppm; hundreds would be a broken part. And ±36.77 ms of offset uncertainty after a settled burst is two orders of magnitude looser than the sub-millisecond figure B3 showed on 26 August.

Why it matters beyond the display

Almost certainly the same fault that put a t0 47 seconds in the future earlier the same day. A relation carries an offset and a rate; converting an instant applies the rate across the interval from the relation's epoch. Between two machines whose boot origins are 6752 s apart, a wrong rate term becomes tens of seconds of error — while the agreement between the clocks is genuinely fine, which is why sync could honestly report 0.0 ms at the same moment.

⚠ So the two numbers were never contradictory. One describes how well the clocks agree now; the other governs extrapolation, and nothing warns that they are different questions.

What is already worked around

The ring is no longer indexed through the host's clock — DetectAndMint keeps the Candidate's own instant, which needs no conversion. That fixed the missing clips. This issue is the estimate itself, which still feeds REQ-SYNC-4's residual and anything else that converts.

To find out

• whether skew_ppm is this wrong on the wire or only in ClockAgreement's reading of it
• whether the burst converged at all, or whether 0.0 ms and ±36.77 ms are two views of an unconverged estimator
• sync_residual cannot be trusted until this is understood — a residual is a difference between two clocks, and one of them is currently claiming to run 18% slow

Recorded in the shared learnings document; a candidate finding for libppcp.

[liversedge]

Narrowed: this is F-D6-2's twin, on the prober side

peer.h names the two paths explicitly:

"an embedding that can stamp closer to the socket than a clock read at decode time supplies the four timestamps itself. The automatic path (a sync_reply arriving, t4 read from the clock as it is handled) is the convenient one; this is the accurate one."

⛔ We are on the convenient one, and we already hold the accurate number. PeerLinkPump computes arrivedAtNs per read and uses it for the responder side — syncReplyStamps(t2Ns:t3Ns:), which is F-D6-2's own fix — then discards it for the prober side. So every offset sample this device measures carries however long the reply sat before being decoded, and this afternoon the pump was starved for tens of seconds at a time.

ppcp_peer_sync_observe has zero callers here and cannot easily gain one: it wants all four timestamps, and t2/t3 live inside the reply body. Supplying them means parsing the frame in the embedding, which is the framing re-implementation the library exists to prevent.

⚠ So ±36.77 ms is the primary symptom and the drift is secondary. RTT on a LAN is sub-millisecond; samples disagreeing by tens of milliseconds are samples delayed by varying amounts. Least squares turns that into a −18% slope, and conversions then extrapolate the slope across the gap between two boot origins — which is how a t0 came out 47 seconds in the future.

What would close it

A prober-side twin of ppcp_peer_sync_reply_stamps: ppcp_peer_sync_arrival(p, t4_ns), applying to the next sync_reply handled and then forgotten. Same shape, same rationale, same clause (6.1c) — and the embedding already has the number in its hand.

One thing worth knowing before anyone measures a residual

⚠ A residual computed against a Shot minted from our own Candidate is ~0 by construction and means nothing. The mint stamps t0 from the Candidate's own instant, so subtracting the two measures a conversion round trip rather than any disagreement between the clocks. REQ-SYNC-4's residual is only meaningful where the host arbitrated from its own detection — which is why the automated run correctly printed not yet, and why exercising it needs PinPointStudio's --corroborate.

The device run now also prints exchanges=n/16, which separates "the burst never converged" from "the burst converged on bad samples".

[liversedge]

The numbers have moved a long way — and the exchange count now answers the question this issue asked

This issue's diagnosis rested on separating two explanations for −184515 ppm: an estimator that never converged, or one fed samples whose t4 includes queueing delay. 6a4e1c2 moved the t4 read late. Measured against a live PinPointStudio on an iPhone 16, 2 September 2026:

	27 August	2 September
Drift	−184 515 ppm	−1 588 ppm
Agreement	± 36.77 ms	± 1.29 ms
Filtered exchanges	—	23 / 16

The burst finished — 23 filtered exchanges against 6.3c's target of 16 — and the estimate is inside a millisecond and a half. The hosted rows also cross 6.1f's 5 ms arbitration gate before arming, at ± 1.31 ms and ± 2.09 ms on separate runs, and a capture_request conversion in the same run printed its relation as skew 1011.37 ppm (σ 1.317 ms / 137.35 ppm) observed 0.2 s before t0.

⚠ Not closing on this, for two reasons. −1588 ppm is still an implausible physical drift between two quartz oscillators — real crystal skew is tens of ppm, not sixteen hundred — so the estimator is now usable rather than right, and this issue's title is about the reading being wrong. And the prober-side twin of ppcp_peer_sync_reply_stamps that §7.3 of mvp-online.md records as this issue's libppcp dependency has not landed.

⚠ Worth restating where this now bites: #28's comment said a residual measured under this estimate is "a reading of #106 before it is REQ-SYNC-4 satisfied". At ± 1.29 ms that caveat is much weaker than when it was written, but a 1588 ppm skew extrapolated over a long session still moves an instant by a millisecond every 0.6 seconds of extrapolation, which is why the capture_request line now prints how long before t0 the relation was observed.