On Tue, 2026-08-04 at 19:59 +0200, Maciek Machnikowski wrote: > > What is the practical use of UNRELIABLE vs UNKNOWN.
It's "known bad" vs. "take it with a pinch of salt and make your own mind up". > I think it can be simplified to UNRELIABLE, SYNCED and HOLDOVER. All > clocks will start in UNRELIABLE, switch to SYNCED whenever the clock > gets synchronized correctly and enter HOLDOVER if it was at the SYNCED > state and report the last synced for that state. Status INITIALIZING has > no practical meaning and requires more work from the APIs, and > HOLDOVER->FREE_RUNNING state transition is undefined (what is > "acceptable" for one application won't be acceptable for another) It feels like we're deep into bikeshedding at this point. We *have* a set of clock status fields defined in the VMClock specification: https://uapi-group.org/specifications/specs/vmclock/ The best time to have this kind of discussion would have been when we were working on that. In general the VMClock fields are largely based on virtio-rtc and designed to be identical to it, but I believe the status field is one of the ones that virtio-rtc dropped (or perhaps never had). We could absolutely have Linux define its own set of status values — but it seems like there would have to be a *significant* improvement of the status quo in order to want to do so, *and* we'd need to be able to map to/from the VMClock values. Even if we could come up with tweaks which would be a better model, having to do that mapping probably ends up being a net loss. Unless we feel strongly enough about these changes that it's worth revising the spec? > Do we need this many timescales defined here? Can't we just use the > notion of TIMESCALE_ARBITRARY and TIMESCALE_ABSOLUTE with the UTC > offset? No, the difference between UTC and TAI is not (yet) just a constant offset. And you can be on TAI without even knowing what the UTC offset is — arguably one of the use cases for TAI is for when you don't *want* to know or care about UTC. > CLOCK_MONOTONIC / MONOTONIC_RAW are really ARBITRARY, is there > any value of differentating between those two? Yes, they behave very differently. The _RAW version doesn't get disciplined. And it's also important to have a clear value for any smeared- leapsecond abomination which *doesn't* pretend it's UTC. > > + > > /* > > * struct ptp_clock_time - represents a time value > > * > > @@ -94,6 +237,136 @@ struct ptp_clock_time { > > __u32 reserved; > > }; > > > > +/* > > + * Hardware counter identifiers for struct ptp_sys_time.sys_counter_id > > + */ > > +enum ptp_counter_id { > > + /* Counter value not available or type not specified */ > > + PTP_COUNTER_UNKNOWN = 0, > > + > > + /* x86 Time Stamp Counter (TSC) */ > > + PTP_COUNTER_X86_TSC = 1, > > + > > + /* ARM Generic Timer virtual counter */ > > + PTP_COUNTER_ARM_ARCH = 2, > > +}; > > + > > +/* Valid flags for struct ptp_clock_attrs.valid */ > > +#define PTP_ATTRS_VALID_ERROR_BOUND (1 << 0) > > +#define PTP_ATTRS_VALID_TIMESCALE (1 << 1) > > +#define PTP_ATTRS_VALID_STATUS (1 << 2) > > + > > +/** > > + * struct ptp_clock_attrs - quality attributes for a PHC timestamp > > + * > > + * @valid: Bitmask of PTP_ATTRS_VALID_* indicating which fields > > + * are populated. Zero means no attributes available. > > + * @error_bound: Maximum error (an upper bound, in nanoseconds) between the > > + * returned device_time and true time on the advertised > > + * @timescale; a worst-case bound, not a statistical > > estimate. > > + * Valid only when PTP_ATTRS_VALID_ERROR_BOUND is set, and > > must > > + * not be trusted when @status is PTP_CLOCK_STATUS_UNKNOWN or > > + * PTP_CLOCK_STATUS_UNRELIABLE. > > + * @timescale: Clock timescale (enum ptp_clock_timescale). Valid only > > + * when PTP_ATTRS_VALID_TIMESCALE is set. > > + * @status: Synchronization status (enum ptp_clock_status). Valid > > + * only when PTP_ATTRS_VALID_STATUS is set. Transitions > > between > > + * states are device-specific; there are no kernel-defined > > + * thresholds relating @status to @error_bound. > > + * @rsv: Reserved for future use, must be zero. > > + */ > > +struct ptp_clock_attrs { > > + __u32 valid; > > + __u32 error_bound; > > + __u32 timescale; > > + __u32 status; > > + __u32 rsv[4]; > > +}; > This does not look like a practical model. Error bounds changes over > time and will get stale by the time you transfer them over IOCTL. > > I think a more practical approach would be to return error_bound > alongside the anchor_timestamp at which it was measured. Huh, is that not exactly how they're used? They're passed in the context of an actual timestamp ioctl. > For example you > can define master_offset for the RX timestamp of the Sync packet, or the > offset for the last 1PPS signal you received. This should be > complemented by some drift_factor that would define how fast it grows. > > If you capture the time from the PHC you can use the formula of > error_bound+(phc_time - anchor_timestamp)*drift_factor to interpolate > the boundaries. I guess we could add that too but it wasn't the primary use case here, as I understand it. A user fetching a timestamp wants to know the bounds of *that* timestamp — what is the latest, and the earliest, that it could actually have been at the time in question. Tracking the *ongoing* error bounds is a different game. > Do we want to squash all errors into a single error_bound - it may make > sense to add the hw_error and sync_error - hw_error would squash > hw-based error bounds (such as clock resolution, GNSS precision) and > sync_error (which would hold the dynamic part derived from the sync > protocol) Where does that end? Individually tracking an arbitrary number of error hops all the way from the master / tier 1 clock? What's important is the total resulting error, isn't it?
smime.p7s
Description: S/MIME cryptographic signature
