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: Problem with generalTime clock synchronization
From: Andrew Johnson <[email protected]>
To: EPICS core-talk <[email protected]>
Date: Tue, 15 Dec 2015 16:56:38 -0600
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). The implementation of the
above routine includes the following code:

>         status = ptp->get.Time(pDest);
>         if (status == epicsTimeOK) {
>             /* check time is monotonic */
>             if (epicsTimeGreaterThanEqual(pDest, &gtPvt.lastProvidedTime)) {

>                 ...

>             } else {
>                 int key;
>                 *pDest = gtPvt.lastProvidedTime;
>                 if (pPrio)
>                     *pPrio = gtPvt.lastTimeProvider->priority;
>                 key = epicsInterruptLock();
>                 gtPvt.ErrorCounts++;
>                 epicsInterruptUnlock(key);
>             }

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.

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.

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

- Andrew

-- 
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
    -- Terry Pratchett, Reaper Man


Replies:
Re: Problem with generalTime clock synchronization Michael Davidsaver

Navigate by Date:
Prev: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Torsten bögershaus
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 
Navigate by Thread:
Prev: Re: Proposed change to asyn drvAsynIPPort for UDP sockets Henrique Almeida
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, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·