Why CLOCK_MONOTONIC?

I’ve come around to using CLOCK_REALTIME because so much infrastructure has been built around it; specifically, PTP on Linux. However, I would like to have another clock besides CLOCK_REALTIME and CLOCK_MONOTONIC that could be synced against PTP, read cheaply from userspace, and timestamp received packets.

There are use cases beyond measuring data-center network latency and multimedia. I work on a real-time robotics platform where some network-connected sensors are synchronized with PTP, and timestamp sensors measurements with their PTP-synced clock. A Linux box in this system has to synchronize its CLOCK_REALTIME against the PTP clock in order to reason about these timestamps against its own local timestamps (reading a NIC’s PTP-synced clock is far too expensive). Although the PTP clock need not be synced against a time close to UTC (I only want to be able to reason about the relative age of sensor readings), I must use a UTC-based time if I want to be able to make use of certificates and have reasonable filesystem timestamps. Moreover, having CLOCK_REALTIME synced against PTP provides a mechanism to timestamp received packets with a PTP-synced clock, which helps integrate network-connected sensors that do not support PTP. This all works, but I don’t like the reliance on CLOCK_REALTIME. Anyone with superuser access can come along and manually slam the clock—this action would cause the whole house of cards to collapse. This is not a vulnerability that I like to have in a robotic system.