EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: generalTime time provider consternation
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Thu, 12 May 2016 16:16:00 -0500
Hi Mike,

On 05/12/2016 02:21 PM, Michael Westfall wrote:
> Our problem comes when the Bancomm board is not locked to it's reference
> signal and happens to have a time set that is in the past compared to
> NTP time.
> EPICS timekeeping becomes erratic and eventually grinds to a halt, and
> records set to scan at periodic rates quit processing.

Is your driver able to tell when it is not locked?

I think the idea is that a time provider must only return OK if it knows
it has a good source of time. I think you need to modify your provider
to return an error when it isn't locked, because only then will the
generalTime code try the next provider in its list.

The code that scans the provider chain is dumb; it will only move on to
the next provider when the first one returns an error (and so on), and
it doesn't remember the state from the last time it scanned the chain,
it always starts again from the top for every request. Thus if a higher
priority provider always returns OK but gives a time in the past, the
current time will not step backwards because of the built-in ratchet
mechanism, but it won't step forwards either until the provider tells it
to, so the periodic scans will hang just as you're seeing.

> Why does time keeping become erratic when  "backwards time" is prevented?

Some code makes use of the OS to time events, but others such as the
periodic scans look at the absolute time.

It has been suggested that the generalTime code needs rewriting again.
Time is a notoriously hard thing to handle properly; some APIs want
absolute times while others want relative times, and keeping the two
synchronized is a problem.

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:
Re: generalTime time provider consternation Michael Westfall
References:
generalTime time provider consternation Michael Westfall

Navigate by Date:
Prev: RE: Model 8743 Closed-Loop Picomotor,Controller / Driver Jemian, Pete R.
Next: RE: Model 8743 Closed-Loop Picomotor,Controller / Driver Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: generalTime time provider consternation Michael Westfall
Next: Re: generalTime time provider consternation Michael Westfall
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·