CLOCK_REALTIME instead of CLOCK_MONOTONIC for PTP coupled RT_PREEMPT systems?

CLOCK_REALTIME instead of CLOCK_MONOTONIC for PTP coupled RT_PREEMPT systems?

[Koehrer Mathias (ETAS/ESW5)]

Hi all,

as far as I know is the standard recommendation to use the clock CLOCK_MONOTONIC with e.g. clock_gettime and clock_nanosleep for real time usage.
I have now the requirement that a couple of (x86) PCs are coupled and synchronized using PTP (linuxptp Project).
The idea of this coupling is that all PCs have always the same (absolute) time stamp (with the PTP accuracy). For this I have to use the clock CLOCK_REALTIME
instead of CLOCK_MONOTONIC.
What speaks against using CLOCK_REALTIME for the real time application?
Are there any drawbacks? 
With our application I can ensure that no manually set of the time occurs.

Thanks for any feedback on this question.

Mathias

Re: CLOCK_REALTIME instead of CLOCK_MONOTONIC for PTP coupled RT_PREEMPT systems?

[Richard Cochran]

On Thu, Jul 24, 2014 at 07:36:06AM +0000, Koehrer Mathias (ETAS/ESW5) wrote:
> What speaks against using CLOCK_REALTIME for the real time application?
> Are there any drawbacks? 

The only drawback is that, in general, someone else might set the
time. This can happen in three ways.

1. local root user calls settime
2. system boots with large time offset, then learns the correct time
   using NTP or PTP, then resets the local clock to match.
3. when using NTP or PTP, the remote root user calls settime

> With our application I can ensure that no manually set of the time occurs.

You also will want to make sure that the application does not start
until case #2 has occurred. Both NTP and PTP provide ways to find out
the synchronization state.

So, if you can control the networked run time environments, then there
is no drawback to using CLOCK_REALTIME.

Thanks,
Richard