Docs: fold the investigation results back into the project docs - #3
Merged
Merged
Conversation
The accuracy investigation left several docs describing a world that no longer exists. Corrects them against what was actually measured. TODO.md: tick the soak item. It was done — 28.8 days, 4119 samples against chrony on serv1, no loss of sync. session.md: the "Still open" list was written mid-investigation and is now mostly resolved — the untracked docs are on main, and the (a) vs (b) question came out as (a). Separates what genuinely remains: the PPS is still trusted against UTC on the NEO-M9N spec, and the packet-path term is bounded rather than measured. HWTIMESTAMPING.md: written while the device was still a suspect for the 0.81ms gap. It isn't one. Marked as optional polish rather than a fix, noting what it would still buy (measuring the packet-path term) and that the asymmetry trap still applies in full. README.md: two claims could be sharpened with real numbers. "expect ~1-3ms offset on wired LAN" — the device's own contribution is bounded at 0.25ms and its time base tracks its own PPS to 5us, so most of what you see is the path. "high variability on wireless ... could be a bug in this firmware" — it isn't. Same device over Wi-Fi vs wired gives offset sd 0.901ms vs 0.207ms and a delay floor of 2.80ms vs 1.05ms, while device-side T3-T2 reads an identical ~26us on both. That open question is closed. Also links TIMEBASE.md from the testing section so the investigation is discoverable from the front page. TESTING.md: analyze_chrony.py measures the device and the network path together. Documents the three tools that separate them, and why the validation pulse takes the host clock out of the loop entirely. Docs only — no firmware or tooling changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The accuracy investigation left several docs describing a world that no longer exists. Corrects them against what was actually measured.
TODO.md: tick the soak item. It was done — 28.8 days, 4119 samples against chrony on serv1, no loss of sync.
session.md: the "Still open" list was written mid-investigation and is now mostly resolved — the untracked docs are on main, and the (a) vs (b) question came out as (a). Separates what genuinely remains: the PPS is still trusted against UTC on the NEO-M9N spec, and the packet-path term is bounded rather than measured.
HWTIMESTAMPING.md: written while the device was still a suspect for the 0.81ms gap. It isn't one. Marked as optional polish rather than a fix, noting what it would still buy (measuring the packet-path term) and that the asymmetry trap still applies in full.
README.md: two claims could be sharpened with real numbers.
"expect ~1-3ms offset on wired LAN" — the device's own contribution
is bounded at 0.25ms and its time base tracks its own PPS to 5us, so
most of what you see is the path.
"high variability on wireless ... could be a bug in this firmware" —
it isn't. Same device over Wi-Fi vs wired gives offset sd 0.901ms vs
0.207ms and a delay floor of 2.80ms vs 1.05ms, while device-side
T3-T2 reads an identical ~26us on both. That open question is closed.
Also links TIMEBASE.md from the testing section so the investigation is discoverable from the front page.
TESTING.md: analyze_chrony.py measures the device and the network path together. Documents the three tools that separate them, and why the validation pulse takes the host clock out of the loop entirely.
Docs only — no firmware or tooling changes.