# SI namespace design

**URL:** <https://forum.opencyphal.org/t/si-namespace-design/207>\
**Category:** Development & Maintenance\
**Created:** [October 21, 2018, 2:28pm UTC](https://forum.opencyphal.org/t/si-namespace-design/207 "2018-10-21T14:28:40Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [November 21, 2018, 8:49pm UTC](https://forum.opencyphal.org/t/si-namespace-design/207/14 "2018-11-21T20:49:05Z")

</div>

> [@pavel.kirienko](#):
>
> 32-bit values with 56-bit timestamps work well with CAN FD: 32-bit payload + 56-bit timestamp + 8-bit tail byte = 96 bits = 12 bytes, which corresponds exactly to the DLC code 10012. Same is true for 3-element vectors: (56 + 32 \* 3 + 8) / 8 = 20 bytes, DLC = 10112, no padding bytes necessary. Although I’m talking about efficiency again here, and we’ve agreed not to do that anymore…

32-bit values with 56-bit timestamps don’t work well with CAN 2.0. They don’t work well at all. Because we don’t fit into one CAN 2.0 frame, we’d have to spill over into another frame, adding two more bytes for CRC. So the overhead would be: 7 bytes timestamp, 2 tail bytes, 4 CRC bytes; the total overhead amounts to 13 bytes for just a single 4-byte float. Uh oh.

I realize that we aren’t supposed to care about efficiency but I’m not sure we’re supposed to _not care_ to such a wild extent.

Kjetil has pointed this out at the today’s call and so we ended up adding `SynchronizedAmbiguousTimestamp`, 24 bits wide, with an overflow interval of 16 seconds. Which is _bad_, because overflowing timestamps are ⚠ _dangerous_, especially those that overflow every 16 seconds.

So, let’s consider for a second dropping the resolution of ambiguous timestamps down to, say, 10 microseconds. This is bad [because of this](https://forum.opencyphal.org/t/on-timestamping/237):

> [@On timestamping](https://forum.opencyphal.org/t/on-timestamping/237/1):
>
> 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).

But 16-second overflow period is also bad, so we have to decide which is worse. Given these new developments, I am inclined to accept timestamps with 10 us per LSB.

---

_[View the full topic](https://forum.opencyphal.org/t/si-namespace-design/207)._