Re: Monotonic time from EPICS Base libCom?

["Kasemir, Kay" <kasemirk@ornl.gov>]

Have you checked the 'General Time' package in libCom, osi/epicsGeneralTime.*?
Inside that lib, you can have several time providers, like NTP, the local clock, your custom timing system receiver.
It fails over between them, and its internal generalTimeGetExceptPriority() checks for monodic behavior.
At least that was the idea.

-Kay

On Nov 13, 2014, at 4:18 PM, "J. Lewis Muir" <jlmuir@imca-cat.org>
 wrote:

> Hello, Tech-Talkers.
> 
> Is there a way to get monotonic time from EPICS Base libCom?
> 
> By "monotonic time," I mean a system time that increases at a steady
> rate and is not affected by a change to the system's RTC.  The origin of
> the time is unspecified, but the difference between two monotonic times
> can be used to compute elapsed time. [1]
> 
> I think the answer is no, but I thought I'd ask.  I'd like a simple way
> to implement a timeout in a C function like this:
> 
>  start_time = epicsTimeGetMonotonic();
>  for (;;) {
>    if (is_data_ready()) goto out;
>    elapsed_time = epicsTimeGetMonotonic() - start_time;
>    if (elapsed_time > timeout) goto timeout;
>    epicsThreadSleep(0.1);
>  }
> 
> Without monotonic time, the closest I can get to this in a simple way
> is to use epicsTimeGetCurrent and epicsTimeDiffInSeconds.  This is
> suboptimal because I have to deal with time that can advance backward
> or forward in an unpredictable way, and it's not possible to correctly
> compensate for that.  For example, if the elapsed time is negative, time
> has advanced backward, and I need to set the start time to the new time.
> This has the undesirable effect of extending the timeout to an actual
> amount of time longer than the caller requested.  If time is slowly
> advancing backward, this could have the undesirable effect of extending
> the actual timeout indefinitely.  And if time has advanced forward
> faster than normal (either by being set or due to a system suspend), it
> would have the undesirable effect of reducing the actual timeout to an
> amount of time shorter than the caller requested.
> 
> Thank you!
> 
> Lewis
> 
> [1] It seems that most, if not all, implementations of monotonic time
>    will suspend the monotonic clock during a system suspend.  This
>    way, programs using time from such a monotonic clock will function
>    normally through a system suspend-resume cycle.  However, if
>    the process itself is suspended, when it resumes, it will see a
>    monotonic time that has advanced "faster" than it expected.  In
>    other words, the monotonic time is per-system, not per-process.  (I
>    see that Linux has a CLOCK_PROCESS_CPUTIME_ID clock type that would
>    overcome this, but I'm not sure something like this is available on
>    the other OSes supported by EPICS.)