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
> 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
> 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?
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
- RE: what was the time before 1990? Davidsaver, Michael
- what was the time before 1990? Davidsaver, Michael
- Navigate by Date:
Re: Lookup table problem Ben Franksen
Re: [Merge] lp:~dirk.zimoch/epics-base/named-soft-events into lp:epics-base Babak Kalantari
- Navigate by Thread:
what was the time before 1990? Davidsaver, Michael
RE: what was the time before 1990? Davidsaver, Michael