Unix Programming - CLOCK

Author

CLOCK_MONOTONIC and

Markus Schaber

2007-09-26, 1:26 pm

Hi,

The Posix documentation states that the "posix realtime extensions"
may provide a CLOCK_MONOTONIC which does not jump backwards (and, at
least on some platforms, not forward) when the system clock
(CLOCK_REALTIME) changes.

But it seems that functions like pthread_mutex_timedlock or
pthread_cond_wait always use CLOCK_REALTIME, and clock_nanosleep seems
to be the only function I can use for a wait on CLOCK_MONOTONIC.

Now, I have some embedded devices which don't have a battery backed
realtime clock, they only get their realtime after some considerable
uptime (imagine GPS, DCF-77 or NTP via GSM Dialin on a device with
bad connectivity).

My application now can cope with getting a REALTIME after some minutes
uptime, but it has a problem with the clock jumps, as that disturbes
our internal timings. Currently, we cope with that by not touching the
system clock, and managing the realtime internally, as an offset to the
now not-jumping sysclock.

Does anybody have a "cleaner" solution? Posix solutions preferred, but
platform specific hacks (for Linux, BSD, etc) could be helpful, too.

Thanks a lot,
Markus

Rainer Weikusat

2007-09-26, 1:26 pm

Markus Schaber <leafnode.use-net@schabi.de> writes:
> The Posix documentation states that the "posix realtime extensions"
> may provide a CLOCK_MONOTONIC which does not jump backwards (and, at
> least on some platforms, not forward) when the system clock
> (CLOCK_REALTIME) changes.

SUS defines now way to set the value of the CLOCK_MONOTONIC clock.
It does define a way to set the value of the CLOCK_REALTIME clock.
In absence of RT extensions, there exists a 'some system clock' and
SUS does not define a way how to set its value.

[...]

> Now, I have some embedded devices which don't have a battery backed
> realtime clock, they only get their realtime after some considerable
> uptime (imagine GPS, DCF-77 or NTP via GSM Dialin on a device with
> bad connectivity).
>
> My application now can cope with getting a REALTIME after some minutes
> uptime, but it has a problem with the clock jumps, as that disturbes
> our internal timings.

'clock jumps' only occur if someone deliberately changes the value of
an adjustable clock to something different. If you care for 'wallclock
time', the best choice would probably to use a ntpd configured to
either get the time from the network or some 'locally attached
reference clock' (eg GPS). But the clock you will then be using is
implemented in software and its actual tick frequency will vary as
required to keep it in line with the reference time source. If you
require a (high-resolution) fixed-frequency clock, using some hardware
oscillator could be a better idea.

Markus Schaber

2007-09-26, 1:26 pm

Hallo,

Rainer Weikusat <rweikusat@mssgmbh.com> schrieb:

> SUS defines now way to set the value of the CLOCK_MONOTONIC clock.

I don't want to adjust CLOCK_MONOTONIC, I want to profit from the fact
that it is not adjustable by relying on it for timing in my
application. That's just the purpose it was defined for. My problem is
that I cannot use that CLOCK_MONOTONIC in some cases I need a
non-adjustable clock (mainly pthread_mutex_timedlock and
pthread_condition_wait), as those are hardwired to CLOCK_REALTIME,
AFAICS.

> It does define a way to set the value of the CLOCK_REALTIME clock.
> In absence of RT extensions, there exists a 'some system clock' and
> SUS does not define a way how to set its value.

Yes, I know that, and I depend on the RT extensions being present.

[vbcol=seagreen]
> 'clock jumps' only occur if someone deliberately changes the value of
> an adjustable clock to something different. If you care for 'wallclock
> time', the best choice would probably to use a ntpd configured to
> either get the time from the network or some 'locally attached
> reference clock' (eg GPS). But the clock you will then be using is
> implemented in software and its actual tick frequency will vary as
> required to keep it in line with the reference time source. If you
> require a (high-resolution) fixed-frequency clock, using some hardware
> oscillator could be a better idea.

Small tick frequency changes won't hurt, as I don't need millisecond
timings. So I don't matter having a 0.99 or 1.01 secs long system
time second.

My Problem is the 'clock jump' that will inevitably occur some time
after system startup, when the system first gets connectivity to that
reference clock. Our application is already running at that time, and
all timeout values will occur at once then.

And, as I wrote, there's no battery backed realtime clock in that
particular hardware, so the NTPD way of small adjustments won't work.

That's why we don't care about adjusting the OS clock at all for now,
and simply maintain the "realtime" as a difference to OS clock
internally in our application, as soon as it's available. That works,
but is butt ugly, and so I asked for a better alternative.

Thanks,
Markus

Rainer Weikusat

2007-09-26, 1:26 pm

Markus Schaber <leafnode.use-net@schabi.de> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> schrieb:
>
>
> I don't want to adjust CLOCK_MONOTONIC, I want to profit from the fact
> that it is not adjustable by relying on it for timing in my
> application.

As long as no other code running on the system adjusts one of the
realtime clocks, there is nor difference between those and
CLOCK_MONOTONIC in this respect. Pointing this out was the purpose of
my paragraph.

[...]

> My Problem is the 'clock jump' that will inevitably occur some time
> after system startup, when the system first gets connectivity to that
> reference clock. Our application is already running at that time, and
> all timeout values will occur at once then.
>
> And, as I wrote, there's no battery backed realtime clock in that
> particular hardware, so the NTPD way of small adjustments won't
> work.

Ntpd does not (normally) do any adjustments to the wallclock, but
speeds it up or slows it down. I am developing (mainly) for a target
platform which has no battery-backed clock either. I am using Kerberos
to secure communication between devices and management servers which
(normally) depends on synchronized clocks. After boot (and before the
ntpd is started), some script executes nptdate in a loop until that
succeeds and creates a semaphore file with a well-known name
afterwards. Any application that needs a correct wallclock waits for
appearance of this file by using Linux (2.4) dnotify (utilizing a
special tool written only for that) before starting.

> That's why we don't care about adjusting the OS clock at all for now,
> and simply maintain the "realtime" as a difference to OS clock
> internally in our application, as soon as it's available. That works,
> but is butt ugly, and so I asked for a better alternative.

If delaying application start is not possible and restarting it isn't
either, the only other option I can think of is to store a 'base time'
for each timeout, use that do determine of the timeout that occurred
was actually due to a clock jump and restart the timeout if it was.

Geoff Clare

2007-09-27, 1:34 pm

Markus Schaber wrote:

> The Posix documentation states that the "posix realtime extensions"
> may provide a CLOCK_MONOTONIC which does not jump backwards (and, at
> least on some platforms, not forward) when the system clock
> (CLOCK_REALTIME) changes.
>
> But it seems that functions like pthread_mutex_timedlock or
> pthread_cond_wait always use CLOCK_REALTIME, and clock_nanosleep seems
> to be the only function I can use for a wait on CLOCK_MONOTONIC.

A system that has CLOCK_MONOTONIC should also have
pthread_condattr_setclock() which you can use to set the clock to be
used for a specific condition variable when you initialise it.

There doesn't appear to be an equivalent for pthread_mutex_timedlock().

--
Geoff Clare <netnews@gclare.org.uk>

Markus Schaber

2007-09-27, 7:37 pm

Hi, Geoff,

Geoff Clare <geoff@clare.See-My-Signature.invalid> schrieb:

>
> A system that has CLOCK_MONOTONIC should also have
> pthread_condattr_setclock() which you can use to set the clock to be
> used for a specific condition variable when you initialise it.

Ah, that's interesting, somehow I completely missed that.

> There doesn't appear to be an equivalent for pthread_mutex_timedlock().

Well, maybe I can get around that with timed conditions only, or wrap
pthread_mutex_timedlock with a loop comparing to CLOCK_MONOTONIC as
suggested by Rainer Weikusat.

Thanks for your suggestions,
Markus