1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 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 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: generalTime time provider consternation |
From: | Michael Westfall <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | [email protected] |
Date: | Fri, 13 May 2016 09:17:13 -0300 |
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