Is steady clock steady system wide?

Question

I am using FastRTPS to communicate between multiple processes on a single Linux system. They are exchanging information in packets. Every packet has a time stamp independent of its sending or receiving time. This way the conveyed information can be used correctly.

I was thinking on using:

uint64_t time_in_microseconds = std::chrono::duration_cast
          <std::chrono::microseconds>(std::chrono::steady_clock::now()
          .time_since_epoch()).count();

to get the timestamp for the packets.

However, is steady clock steady across processes on a single system? Or only inside a single process?

If not, how much does the system clock vary under normal conditions? How much would it move "back in time"? (not adjusting it manually, no internet connection, no time change, etc.)

Thank you

Edit:

The packets will be used in state estimation and control algorithms. Sensor data will, for example, move from a sensor reading process to a state estimation process. State information will move from the estimation process to the control process. That is why I need to be able to measure intervals consistently across the system. Neither system_clock nor steady_clock seem to provide what I need. System_clock is consistent, but its not monotonic. And steady clock is monotonic and consistent inside a single process, but as far as I can see, it is not consistent across the system? Or is it?

I'm not sure about the existing clocks, but C++20 introduces `utc_clock`, `tai_clock`, `gps_clock` and `file_clock` which should all be synchronized across the system. The first three should be synchronized across the world, if they are available. — François Andrieux, Jun 20 '19 at 17:16
By the way, how many messages can you send through in a microsecond? Perhaps consider adding sequence numbers, too, if ordering is important to you and there's any chance it could be lost somewhere in the chain. — Lightness Races in Orbit, Jun 20 '19 at 17:36
Does actual time really matter or are you only after a known ordering? — user4581301, Jun 20 '19 at 18:33
Yes, actual time matters. Ordering is not sufficient. The packets will be used in state estimation and control loops. — Fabian, Jun 21 '19 at 09:01
This same question is discussed here: https://stackoverflow.com/q/30882953/4029784 My understanding is that the standard doesn't guarantee same epoch for different processes (because of the lack of "system-wide" requirement for steady_clock). It would be nice to get a confirmation for this from someone who actually understands the std::chrono design, though. — khuttun, Jan 10 '20 at 09:12

Oblivion · Accepted Answer · 2019-06-20T17:42:20.523

4

steady_clock is more suitable for measuring intervals.

std::chrono::steady_clock represents a monotonic clock. The time points of this clock cannot decrease as physical time moves forward and the time between ticks of this clock is constant. This clock is not related to wall clock time (for example, it can be time since last reboot), and is most suitable for measuring intervals.

system_clock is system wide and probably what you need but may not be monotonic:

Class std::chrono::system_clock represents the system-wide real time wall clock. It may not be monotonic: on most systems, the system time can be adjusted at any moment. It is the only C++ clock that has the ability to map its time points to C-style time, and, therefore, to be displayed ^{[until C++20]}

The epoch will be changed from will be changed from c++20

system_clock measures Unix Time (i.e., time since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds). ^{[since c++20]}

edited Jun 20 '19 at 17:42

answered Jun 20 '19 at 17:21

Oblivion

7,176
2
14
33

1

But neither seems suitable for measuring intervals across the system. – François Andrieux Jun 20 '19 at 17:23
@FrançoisAndrieux seems it will be changed from c++20 – Oblivion Jun 20 '19 at 17:28
`system_clock` was synchronized across the system even in C++11. The C++20 changes only specifies the epoch along with a few new features. It also notably does not make it monotonic. – François Andrieux Jun 20 '19 at 17:32
Please provide links/citations for words that aren't your own. i.e. give credit. It also provides some chain of evidence for your claims. – Lightness Races in Orbit Jun 20 '19 at 17:34
@LightnessRacesinOrbit added the links. thanks for reminding – Oblivion Jun 20 '19 at 17:39
@FrançoisAndrieux Yes, that is my problem. I need to be able to measure intervals across the system consistently. Neither system_clock nor steady_clock seems to provide what I need. – Fabian Jun 21 '19 at 09:07

score 1 · Answer 2 · answered Jun 20 '19 at 17:26

You can use the kernel packet timestamps, see SO_TIMESTAMP family:

The interfaces for receiving network packages timestamps are:

SO_TIMESTAMP

Generates a timestamp for each incoming packet in (not necessarily monotonic) system time. Reports the timestamp via recvmsg() in a control message in usec resolution. SO_TIMESTAMP is defined as SO_TIMESTAMP_NEW or SO_TIMESTAMP_OLD based on the architecture type and time_t representation of libc. Control message format is in struct __kernel_old_timeval for SO_TIMESTAMP_OLD and in struct __kernel_sock_timeval for SO_TIMESTAMP_NEW options respectively.

SO_TIMESTAMPNS

Same timestamping mechanism as SO_TIMESTAMP, but reports the timestamp as struct timespec in nsec resolution. SO_TIMESTAMPNS is defined as SO_TIMESTAMPNS_NEW or SO_TIMESTAMPNS_OLD based on the architecture type and time_t representation of libc. Control message format is in struct timespec for SO_TIMESTAMPNS_OLD and in struct __kernel_timespec for SO_TIMESTAMPNS_NEW options respectively.

IP_MULTICAST_LOOP + SO_TIMESTAMP[NS]

Only for multicast:approximate transmit timestamp obtained by reading the looped packet receive timestamp.

SO_TIMESTAMPING

Generates timestamps on reception, transmission or both. Supports multiple timestamp sources, including hardware. Supports generating timestamps for stream sockets.

Is steady clock steady system wide?

2 Answers2