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?
Defined in header <chrono> class steady_clock; (since C++11) Class 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.
std::chrono::system_clock::now Returns a time point representing with the current point in time.
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]
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With