Re: Problem with generalTime clock synchronization

[Michael Davidsaver <mdavidsaver@gmail.com>]

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