EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: what was the time before 1990?
From: Andrew Johnson <[email protected]>
To: "Davidsaver, Michael" <[email protected]>, "EPICS core-talk" <[email protected]>
Date: Fri, 22 Oct 2010 17:19:51 -0500
On Thursday 21 October 2010 17:04:14 Davidsaver, Michael wrote:
> Since the seconds part of struct epicsTimeStamp is unsigned how should
> times before 1990 be handled?

IMHO They shouldn't be able to be represented.  When converting from a format 
that _can_ represent them we should throw or return an error, depending on the 
language requesting the conversion.

However as you discovered we don't do that at the moment, although we do have 
the ability to return an error from epicsTimeFromTimespec().  The osiNTPTime.c 
code isn't currently checking that return value either.

> Had a problem last night here the time reported by generalTime jumped
> back to 1936 for several hours.  There are three problems here 1) it
> jumped back to 1936, 2) that it came back, and 3) where the time got
> corrupted initially.  This is on the same RTEMS IOC that I say the NTP
> broadcast weirdness, but has that patch.
>
> After some investigation it seems that the time conversion and
> comparison calls in epicsTime.h are broken when dealing with times
> before the Epoch.  Some attempt is made, but it doesn't work right.
> This is why 2010 < 1936.  I still don't know how it came back to 2010 by
> itself.  I assume there are some inconsistent signed/unsigned
> comparisons somewhere.
>
> I'd recommend adding a check in NTPTimeSync() which flatly rejects if
> osdNTPGet() returns a time before the EPICS Epoch.  This has to be done
> to the timespec before calling epicsTimeFromTimespec().

I will add that, and check the return value from epicsTimeFromTimespec() too, 
although I think it would be better to have the epicsTime conversion routines 
reject external times from before EPICS epoch; we shouldn't have to check that 
range for ourselves.

> Attached are some additional tests for epicsTimeTest which illustrate
> some of the problems.

Thanks, some of these are definitely worth adding, but not into 3.14.12.  I 
would personally prefer to simplify the epicsTime code to not handle roll-
overs at either end, although I'd be happy to reject just the bottom end to 
begin with.  I've already tested that change, which will probably go into 
3.15.

> The other fun thing I discovered is that while time was doing wacky
> things the timer queues stopped working since they are based on
> wallclock time.
>
> This lead me to notice that generalTime does not fallback to a lower
> priority source when it encounters a backwards time error, but just
> stops time (perhaps indefinitely).  I think that we should make the CPU
> tick counter or Monotonic clock available to use with things like timers
> where it is important that they do not stop.

That may be regarded as a bug in generalTime, but I'd want to review it in a 
bit more detail before making any changes.  If the NTP server goes offline for 
some time and there are IOCs whose tick timers run fast, their current time 
would get ahead of the NTP server's.  When the NTP server comes back online 
and the NTPTimeSync processes resynchronize, their NTP time providers will 
give out a time that is earlier than the last time from the tick clock.  We 
have to adjust the clock in that circumstance, the question is how.

The current code in generalTime freezes the current time that it reports until 
the NTP time catches up, and because our timers trigger on an absolute time, 
they will stop during that catch-up period — a bit crude I admit.  I wouldn't 
want to base periodic timers off a tick clock alone though, because users 
don't like it very much if they get 103 notifications from a 10Hz timer in a 
10 second period.

To fix that I think we'd need to make generalTime more like an NTP daemon that 
accepts multiple different clock sources, measures them against each other and 
develops an idea of how well they all work, then derives a composite time from 
all the information it has.  I don't feel the need to work on that myself 
though.

> Ps. Are there really systems which implement time_t as a floating point
> type?  Some of the code in epicsTime.cpp really surprised me.

I don't know of any; Jeff do you?

Thanks,

- Andrew
-- 
If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it.  If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence.  -- Bertrand Russell



Replies:
RE: what was the time before 1990? Davidsaver, Michael
References:
what was the time before 1990? Davidsaver, Michael

Navigate by Date:
Prev: Re: Lookup table problem Ben Franksen
Next: Re: [Merge] lp:~dirk.zimoch/epics-base/named-soft-events into lp:epics-base Babak Kalantari
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: what was the time before 1990? Davidsaver, Michael
Next: RE: what was the time before 1990? Davidsaver, Michael
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·