EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Problem with generalTime clock synchronization
From: Michael Davidsaver <[email protected]>
To: Andrew Johnson <[email protected]>, "J. Lewis Muir" <[email protected]>, <[email protected]>
Date: Wed, 16 Dec 2015 18:16:43 -0500
On 12/16/2015 05:26 PM, Andrew Johnson wrote:
> Hi Lewis,
>
> On 12/16/2015 10:10 AM, J. Lewis Muir wrote:
>> On 12/15/15 6:39 PM, Andrew Johnson wrote:
>>> On 12/15/2015 05:19 PM, Michael Davidsaver wrote:
>>>> I would point out that allowing jumps backwards will allow timers to
>>>> expire early as the timer queue uses general time.
>>> The epicsEventWaitWithTimeout() and epicsThreadSleep() APIs are both
>>> safe since they're implemented using tick counts on the two RTOS's,
>>> but you're talking about Jeff's epicsTimer implementations, which I
>>> now see do absolute time comparisons to determine when a timer should
>>> go off.
>> Hi, Andrew!
>>
>> So those two APIs are safe on the two RTOSes (vxWorks and RTEMS, I
>> assume), but not on others, right?  Obviously, there are *lots* of soft
>> IOCs out there, so this issue would apply to all of those.
> None of the other OSs use generalTime to set their time-of-day clock,

Which is to say that all IOCs call through generalTime, but most have
only one provider ("OS Clock").  So times fetched are currently always
subject to the backwards time check.

> epics> generalTimeReport
> Backwards time errors prevented 0 times.
>
> Current Time Providers:
>     "OS Clock", priority = 999
>         Current Time is 2015-12-16 18:06:18.174206.
>
> Event Time Providers:
>         No Providers registered.



> they all have some other OS-specific way of synchronizing with NTP, so
> the particular issue that I was discussing here doesn't apply to them in
> quite the same way. If the OS allows the time to jump, that may have
> similar effects on any OS APIs that handle time and delays, such as
> select(), nanosleep() etc.



>
>
>>> I'm not sure how big a problem this is in practice.
>> To me, a timer or similar API that expires early is a bug (unless
>> documented to allow for early expiration, but that might make the API
>> difficult to use or worthless) and can lead to all kinds of problematic
>> behavior.  I would love for all timers to work correctly on all
>> platforms.  I'm not closely following the core development, but perhaps
>> you could implement a monotonic time source and use it for soft IOC
>> timer implementations.
> As I see it there are two different kinds of timers that users might
> want to use. In some cases they want a timer that will fire "at least N
> seconds from now", while in others they want one that will fire "as soon
> as possible after absolute time T". The epicsTimer classes actually
> provide both methods:
>     void start (epicsTimerNotify &, double delaySeconds);
>     void start (epicsTimerNotify &, const epicsTime &);
>
> However they only implement what they promise when the wall-clock time
> advances smoothly. The first method is actually implemented by calling
> epicsTimeGetCurrent(), adding the delay and then calling the second
> method, thus if the wall-clock time returned by epicsTimeGetCurrent()
> ever jumps forward while an epicsTimer using the delay method is
> ticking, it may fire before the requested delay is up. If the timer was
> given an absolute trigger time though, I would want it to trigger as
> soon as the requested wall-clock time arrived.
>
> If we had a true monotonic clock as you and Michael propose we could use
> that to implement the delay timer to avoid early triggers, but we would
> have to be careful not to break timers triggered with an absolute time —
> they should continue to use something like the current implementation.

Some work on epicsTimer will be in order I agree.  Correctly supporting
both relative and deadline timers in one timer queue will be interesting...


Attachment: signature.asc
Description: OpenPGP digital signature


References:
Problem with generalTime clock synchronization Andrew Johnson
Re: Problem with generalTime clock synchronization Michael Davidsaver
Re: Problem with generalTime clock synchronization Andrew Johnson
Re: Problem with generalTime clock synchronization J. Lewis Muir
Re: Problem with generalTime clock synchronization Andrew Johnson

Navigate by Date:
Prev: Re: Problem with generalTime clock synchronization Michael Davidsaver
Next: Fwd: Wrong beacon source IP address Ralph Lange
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Problem with generalTime clock synchronization Andrew Johnson
Next: Re: Problem with generalTime clock synchronization Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·