Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Added explicitness to `uavcan::time` #50
The following things are, in my opinion, improved by this change.
The drawback is that nodes will saturate the timer in 285 years instead of 2k years. But the current changes also allows a system to smoothly migrate to a different time frame starting in 2200 when we're approaching 2265 (GPS time + 285).
I like the general idea, but how about altering the implementation a bit. I am generally against unnecessary unions because they restrict our ability to type-check statically and require applications to perform additional computations to handle types at runtime, but this seems like a worthy exception. How about we define some new types:
...each containing a
Then we define
Regarding negative time, I am not entirely sure whether we need that. Seeing as these types are generally intended for time stamping and synchronization, we are unlikely to need negative time unless we time-traveled back to the 20th century. To support negative time we'd have to either limit ourselves to just four time bases forever, reduce the resolution, or to further reduce the already limited range of 285 years even further; can we really afford any of that?
Do we really want a dedicated monotonic time, considering that we already have
The new per-time-base types will allow us to require particular time bases statically when required; e.g. for the file info message we would just use
I'm OK with your proposal of types.
Most of these timescales provide dates many years previous to today even without negative numbers. I suspect the ability to be able to add more timebases at a later point will be more valuable than negative numbers. Changing the range to [-140, +140] years? I don't think it's better, but not completely certain.
I agree. Should we perhaps require boot to be monotonic?
I will not be able to do much before Wednesday, feel free to hijack the PR if you want it done faster.
We're on the same page.
Yes; in fact, we could just call it
No rush, this can wait.
I thought about this some more and realized that we should discuss this further.
The old (current) approach is to state that there is some time base of unknown origin that all nodes must sync with not knowing its properties, other than that its rate of progress is close to 1 second per second. The minimal information provided by the old (current) solution is enough to convey and reason about temporal relationships between data items, which is the only problem addressed by sensor feed timestamping.
Actually, for the old (current) approach, time is irrelevant. The objective is to cluster related measurements together. It is convenient to use time for that, but it could be any other source of unique identifiers as long as it is available to all nodes uniformly.
The new approach adds more context and complicates timestamping, requiring nodes to not only sync their clocks, but also to remember what type of clock is currently in use.
We should further think about that and detail whether it is permitted for time sync masters to broadcast sync messages carrying several different time bases simultaneously, and if so, how time sync slaves (and other masters) should react to that. If there are multiple time bases concurrently available in the system, which one is used for timestamping? Should we prioritize them? Should we prohibit such plurality?
I have thought about it some more; what follows is just an idea, not sure about its merits.
We could add the explicitness while avoiding the complications I talked about earlier if we were to report the time base in use with the time sync messages and remove that information from timestamps.
The time synchronization message
On the other hand, one might question whether such discrepancy between time syncing and time stamping actually makes things even more unnecessarily involved.
I agree, but would like to push it a bit further.
It seems like there are many different use cases for timestamps and as many arguments for different resolutions (s/ms/us) and bit lengths. It, therefore, seems like defining a
It might be more useful to define some standard time reference that we use throughout the standard definitions and use the resultion/size that fits best with the applications, and even allow small overflowing timers where that make sense.
This would make it idiomatic to use 53 bits in sync timestamps, 56 where needed, and would even make the 32 bits second counter in
I've updated the PR to reflect this, what do you think?
Indeed. That would pretty much bring us back to where we started. What I like here is that we make things simple yet flexible by going back from
I think we don't gain a lot by unifying timestamping with more specialized usages like the node uptime counter or file modification time since they serve different purposes, but it's still nice to have for consistency.
I would really like to hear more opinions on this as we seem to be a bit stuck here.
Let me go back to what I said earlier here. The main purpose of timestamping is the detection of temporally-near data items. For that purpose, the exact point of origin of time does not matter; what matters instead is that the point of origin is the same and the rate of progress of time is similar for all nodes across the network. That suggests that, as discussed, data timestamps should be just plain integers, without any additional time system specifiers. I would still like, though, to wrap the plain integer into a container type, because that facilitates type safety and generic programming (see the previous post), and the type of timestamp can be chosen to suit the vast majority of sensor timestamping needs:
It has been proposed here that the synchronization message would carry some information about the time value contained therein. I think we would all agree that changing the time base on a live system should be prohibited, as such a transition would undoubtedly introduce all kinds of nasty transients that can severely disrupt the operation of real-time processes. This also implies that if there is more than one time sync master in the system, they all must adhere to the same time base (TODO spec this). The upshot is that if there is any time base information included in the time sync message, it would stay constant for the entire operating time of the bus, which makes this information redundant to have in every message. I propose that we define the sync message as before, except that we use a plain integer for the avoidance of confusion:
And then we also provide a service that can be made mandatory for all time sync masters, which provides information about the reported time, and this information is also required to stay constant as long as the node is running (other fields such as leap seconds are allowed to change, obviously, since they are out of control of the time sync master):
I am beginning to question the validity of UTC for time synchronization needs given its inherent dependency on the Earth's rotation; see https://derickrethans.nl/leap-seconds-and-what-to-do-with-them.html:
All other uses of time, e.g. the file modification time and the node uptime, should probably stay as they are because they need to adhere to completely different requirements (very low resolution, very low precision, synchronization not needed, the uptime is always monotonic).