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, >Pvt.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
<2015>
2016
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
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|