Homepage GitHub

On timestamping


(Pavel Kirienko) #1

There have been reports that the current approach to timestamping is too wasteful, as every timestamp is represented by a large 56-bit wide unsigned integer. There have been suggestions to utilize a more compact form for the sake of lower transfer fragmentation, lower bus load, and lower latency.

The reason why we use large 56-bit timestamps is because they provide an unambiguous context-independent representation of a point in time. A 56-bit timestamp value contains an immediately usable value that never expires and is always valid.

As we are beginning to rely on timestamping heavily, I would like to resurrect this discussion once again to have this question settled for UAVCAN v1.0.

Let us discuss the advantages and disadvantages of smaller overflowing expirable timestamp representations. I would like to avoid talking about representations that offer a reduced resolution (lower than one microsecond) for reasons of consistency and avoiding introduction of new restrictions on application design (a message that relies on a compact timestamp may also require full microsecond resolution).

The standard 56-bit microsecond timestamp would overflow in 2284 years, which means virtually never.

A reduced 32-bit microsecond representation would overflow in 1 hour and ~12 minutes while being 24 bit shorter and introducing an additional computational burden on the application.

Neighboring byte-aligned representations (namely, 24-bit and 40-bit) do not seem to be worth the effort as one of them would overflow too frequently (16 s), and the other does not offer a significant improvement over the full timestamp (being only 16 bit shorter).

The following calculation does not show any improvement for 32-bit timestamps with CAN FD, as the freed up space would be used by padding bytes anyway:

Do we want this?


Weekly dev call - Meeting notes
Weekly dev call - Meeting notes
SI namespace design
SI namespace design