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