[Bug 1392516] Re: OSI monotonic time source

[Andrew Johnson via Core-talk <core-talk@aps.anl.gov>]

** Changed in: epics-base
       Status: New => In Progress

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1392516

Title:
  OSI monotonic time source

Status in EPICS Base:
  In Progress

Bug description:
  There is a need for seperate real (wall clock) and monotonic time
  sources.

  On 11/13/2014 04:18 PM, J. Lewis Muir 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.)
  >

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1392516/+subscriptions