Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Thu, 21 Oct 2010 18:04:14 -0400

Since the seconds part of struct epicsTimeStamp is unsigned how should
times before 1990 be handled?

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().

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

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.

Anyway, I'm going to be on vacation for the next 5 days (assuming time
is in fact linear) so email will be sparse.

Michael

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System