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: <[email protected]>
Date: Tue, 15 Dec 2015 18:19:12 -0500
On 12/15/2015 05:56 PM, Andrew Johnson wrote:
> The implementation of generalTime in libCom has a fairly serious problem
> for some configurations which I believe needs fixing.
>
> This public API
>     int generalTimeGetExceptPriority(epicsTimeStamp *pDest,
>         int *pPrio, int ignore)
> was included mainly to allow time providers that do not themselves have
> an absolute time reference to synchronize with some other provider that
> does (but may have a lower time resolution).

FYI, mrfioc2 also uses this to initialize the EVG's time from its NTP
source (since this can't be queried directly w/o OS dependent calls).

>  The implementation of the
> above routine includes the following code:
>
> ...
> Thus if a higher-priority high-resolution clock runs slightly fast the
> absolute time now will always be earlier than the last time we provided
> to our callers, and there is no way with the above code to correct the
> absolute time of the high-res clock. At most it will be corrected by
> however long it was since the last time it was read, which on a busy IOC
> might not be much.

Gosh, I wish I'd communicated this more clearly as this issue has been
known (to me at least) for some time.  It's usually partially masked by
the fact that the event system time providers, that I'm aware of, don't
take into account propagation delay from the EVG, and thus report a
slightly earlier time.

> For this particular API I suggest that we *should* allow the time to go
> backwards, since that is necessary to properly synchronize the clocks.
> We should still keep the backwards-time-prevention code on the main
> epicsTimeGetCurrent() routine (actually we'd have to move it into that
> routine which currently just calls the above) so the IOC will never see
> time going backwards, but the clocks themselves need to be able to
> synchronize both backwards and forwards.

Agreed.  I consider that this design can't really ever work as it has
contradictory goals.  It wants to be monotonic (can't jump back) and
provide wall clock time (can jump back).

>
> Comments please; unless there are objections I plan to implement this
> change for the 3.14 branch.

I'd like to see what exactly your doing, but I don't think this will be
an issue.

I would point out that allowing jumps backwards will allow timers to
expire early as the timer queue uses general time.  Changing this
situation is the motivation behind:

https://bugs.launchpad.net/epics-base/+bug/1392516

https://code.launchpad.net/~epics-core/epics-base/monotonictime/+merge/269124



Replies:
Re: Problem with generalTime clock synchronization Andrew Johnson
References:
Problem with generalTime clock synchronization Andrew Johnson

Navigate by Date:
Prev: Problem with generalTime clock synchronization Andrew Johnson
Next: Re: Problem with generalTime clock synchronization Andrew Johnson
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: Problem with generalTime clock synchronization Andrew Johnson
Next: Re: Problem with generalTime clock synchronization Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·