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