feat: tell the collector how far to trust the timestamp - #37
Merged
Conversation
timeQuality (RFC 5424 section 7.1) joins the record, and meta gains sysUpTime. Store-and-forward is the next stage, and it breaks the assumption that a record's timestamp is close to when the collector saw it — so the device says what its clock is actually worth before that assumption goes. wire ... BOOT [meta sequenceId="1" sysUpTime="362"][timeQuality tzKnown="1" isSynced="0"] device started Flash +7,612 B (+292 on the previous stage) RAM +5,880 B (+24) Log stack +448 B (unchanged) Service +672 B (unchanged) isSynced is 0 and stays 0. This device reads the host clock once at boot and then free-runs on the FreeRTOS tick: enough to stamp a record, not synchronisation, and an operator is better served by being told so than by an unqualified timestamp. RFC 5424 section 7.1.3 forbids syncAccuracy when isSynced is 0, so it is omitted rather than guessed. tzKnown is 1 — the device works in UTC throughout and knows it. sysUpTime lands here rather than beside sequenceId because it answers the same question the clock does: after a reboot the sequence restarts at 1, and an uptime near zero is what distinguishes that from a counter wrap. Adding it is one more field on a config struct that already existed, which is the point — an SD-ID grows a PARAM at a time and nothing downstream notices. One constraint worth knowing: SolidSyslogFreeRtosSysUpTime_Get is guarded at compile time, and with a 32-bit TickType_t it rejects any configTICK_RATE_HZ that does not divide 100. This device runs at 100 Hz and builds; a 1000 Hz device would not, and the escape is to supply your own SolidSyslogSysUpTimeFunction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughSyslog now publishes ChangesTime quality structured data
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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.
Pull request
What this stage adds
timeQuality (RFC 5424 section 7.1) joins the record, and meta gains sysUpTime.
Store-and-forward is the next stage, and it breaks the assumption that a record's
timestamp is close to when the collector saw it — so the device says what its clock
is actually worth before that assumption goes.
wire ... BOOT [meta sequenceId="1" sysUpTime="362"][timeQuality tzKnown="1" isSynced="0"] device started
Flash +7,612 B (+292 on the previous stage)
RAM +5,880 B (+24)
Log stack +448 B (unchanged)
Service +672 B (unchanged)
isSynced is 0 and stays 0. This device reads the host clock once at boot and then
free-runs on the FreeRTOS tick: enough to stamp a record, not synchronisation, and
an operator is better served by being told so than by an unqualified timestamp.
RFC 5424 section 7.1.3 forbids syncAccuracy when isSynced is 0, so it is omitted
rather than guessed. tzKnown is 1 — the device works in UTC throughout and knows it.
sysUpTime lands here rather than beside sequenceId because it answers the same
question the clock does: after a reboot the sequence restarts at 1, and an uptime
near zero is what distinguishes that from a counter wrap. Adding it is one more
field on a config struct that already existed, which is the point — an SD-ID grows a
PARAM at a time and nothing downstream notices.
One constraint worth knowing: SolidSyslogFreeRtosSysUpTime_Get is guarded at compile
time, and with a 32-bit TickType_t it rejects any configTICK_RATE_HZ that does not
divide 100. This device runs at 100 Hz and builds; a 1000 Hz device would not, and
the escape is to supply your own SolidSyslogSysUpTimeFunction.
Files
Checklist
measurements/time-quality.csvcommitted.measurements/stages.tsv.python3 scripts/gen-cost-table.py../run.shgreen (build + QEMU + baseline self-check) —run-report.mdcommitted.Context for review: 10 of 21 sequential single-commit PRs replaying the integration on top of the Baseline root. Each lands green and reviewed before the next is built on it, because a change to an early commit would force every commit above it to be re-run and re-measured.
Summary by CodeRabbit
New Features
Documentation