CLOCK_MONOTONIC and - Unix

This is a discussion on CLOCK_MONOTONIC and - Unix ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: CLOCK_MONOTONIC and

  1. CLOCK_MONOTONIC and

    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

  2. Re: CLOCK_MONOTONIC and

    Markus Schaber 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.

  3. Re: CLOCK_MONOTONIC and

    Hallo,

    Rainer Weikusat 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.

    >> 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.


    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

  4. Re: CLOCK_MONOTONIC and

    Markus Schaber writes:
    > Rainer Weikusat 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.


    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.

  5. Re: CLOCK_MONOTONIC and

    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

  6. Re: CLOCK_MONOTONIC and

    Hi, Geoff,

    Geoff Clare schrieb:

    > > 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.


    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

  7. Re: CLOCK_MONOTONIC and

    Does CPU affinity have anything to do with CLOCK_MONOTONIC?


    I have my kernel with smp and when i try to set cpu ie CPU_SET(1,xx)....and if i try to get the time using clock_gettime()......i am not getting correct values ie the clock is not giving me an always incrementing value.......does anybody experienced this kind of problem?

+ Reply to Thread