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: Andrew Johnson <[email protected]>, <[email protected]>
Date: Wed, 16 Dec 2015 18:03:54 -0500
On 12/15/2015 07:39 PM, Andrew Johnson wrote:
> On 12/15/2015 05:19 PM, Michael Davidsaver wrote:
>> 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).
> I've been working on a major new release of the apsEvent system, so
> similar to your experience.

Perhaps some more details are in order?  You want to access NTP time? 
Maybe this would be better addressed in 3.14.x by adding a call to query
the NTP source directly?

>
>> I'd like to see what exactly your doing, but I don't think this will be
>> an issue.
> See attached patch, untested at this point though.

At first glance I don't like the idea of changing the behavior of
generalTimeGetExceptPriority() wrt. epicsTimeGetCurrent() at all, and
not in a 3.14 release.

If you do want to make a fix in 3.14 series I'd suggest to add your
modified generalTimeGetExceptPriority() as a new function.  Also don't
set lastTimeProvider.

This avoids having to worry about breakage in the stable release series.

>
>> I would point out that allowing jumps backwards will allow timers to
>> expire early as the timer queue uses general time. 
> ...
> you're talking about Jeff's epicsTimer implementations, which I now see
> do absolute time comparisons to determine when a timer should go off.

Correct.

> I'm not sure how big a problem this is in practice.

That's the problem, neither am I.

> We could apply a configurable maximum limit to the time change that we
> send to the clock_settime() routine, and make the ClockTimeSyncInterval
> a configurable parameter instead of a macro. Alternatively maintain an
> offset to the OS clock that we slowly adjust.
>
> The osiNTPTime provider currently never returns a backwards jump, but I
> suspect that could be taken out. In fact the code could be rewritten to
> measure the actual OS tick rate and correct it against the NTP server.

All quite reasonable, just not I think appropriate for 3.14.

(I would love to remove of timeListLock)

>> 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
> Obviously related, but not quite the same issue IMHO.



Attachment: signature.asc
Description: OpenPGP digital signature


References:
Problem with generalTime clock synchronization Andrew Johnson
Re: Problem with generalTime clock synchronization Michael Davidsaver
Re: Problem with generalTime clock synchronization Andrew Johnson

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