Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Fri, 04 May 2007 11:02:19 -0400

You are right, the provider for a "get current" call should always be
moving forward. We have not seen any such deadlocks since implementing
generalTime (as it is now).

Here is why:

Our vxWorks targets make a call to get set the on board clock to NTP
before any epics start up script runs, so that clock_gettime() is close
to correct for at least as long as epics takes to start up.  Even if not
all of the time providers are ready at least the base one will provide
the time no matter what.  Since it needs no initialization it should
always work.  The higher priority providers that are still initializing
should decline providing the time so in the end clock_gettime() will be
called in the base provider.

In no case should one ever set the internal clock on a running system
like vxWorks without knowing the consequences or doing it in small
steps. The vxWorks OS does not use the current time for task scheduling
or delays, it uses a tick counter, so it is OK to set the time once
before the application code is loaded.   Epics does not use anything
like a tick counter for scheduling because such an implementation is not
portable.

On everything except vxWorks, and maybe RTEMS, clock_gettime() has NTP
support built in and all of the PLL and transport delay compensation
machinery is in the OS.  Putting generalTime in base makes it possible
to have an event time implementation available on all platforms.

----

By providing a get time and an event time priority to the driver you
control which providers that you prefer to get called first.

-----Original Message-----
From: Denison, PN (Peter) [mailto:[email protected]] 
Sent: Friday, May 04, 2007 7:10 AM
To: Thompson, David H.; [email protected]
Cc: Kasemir, Kay; Kalantari Babak; Andrew Johnson; Korhonen Timo
Subject: RE: generalTime & EventTime

> From: Thompson, David H. [mailto:[email protected]]
> 
> The calls to epicsTimeGetCurrent()  come from task schedulers and the
> calls to epicsTimeGetEvent() come from record processing.  It seems to
> me that you would always need to have at least one instance of both
> kinds of providers in a system, and they can be the same.  For
> getCurrent calls you want a stable monotonic source, for getEvent
calls
> you want a  timing system time if you can get it.  Thus two priority
> lists generally in opposing order.

I think it's really important that whatever happens and whatever drivers
for time providers you have loaded, that timers still continue to count.
At the moment, the epicsTimer infrastructure relies on
epicsTime::getCurrent()
and so all sorts of things break if "time" stops ticking. Of particular
importance is the period during startup that may be before the time
provider has been fully initialised, but after you've registered it.

I know that this is what generalTime is all about, but we need to make
sure
that all the "ticking" things in epics core are checked that they behave
with
the proposed changes to the infrastructure.

We've just seen a couple of instances where an IOC deadlocked during
iocInit, because a streamDevice protocol @init handler was waiting for
an
asyn input timeout, but for some reason the EVR had not been properly
configured and time wasn't ticking. I'm looking forward to being able to
try out generalTime.

> You can define what event "0" means in your event provider, in our
case
> it is the current time from the timing system.  In our case records
> processed with event '0' during a given machine cycle all have the
time
> stamp if the IOC has access to the timing system.  In Stephanie's case
> the event time provider can always return an error if it does not have
a
> time for the event specified (in the record).
> 
> The iocTimeManager must provide a user handle to time provider
> functions. I guess a C++ object is out of the question.
> 
> I agree that the startup API should provide the ability to set
> priorities and names for multiple instances as well as an input
> specification.  Remember it is otherwise an epics driver the same as
any
> other.

Although it's not very elegant, the EventTime driver could just use the
"first-configured" EVG/EVR in the system. The same applies to NTP
providers,
and anything else.

However, the scheme proposed by Kay seems to be the best. It does mean
that there's more to get right in writing a time provider, but the "user
argument" should allow ultimate flexibility.

-- 
Peter Denison, Senior Software Engineer
Diamond Light Source Ltd., Diamond House, Chilton Didcot, Oxon, OX11 0DE
+44 1235 778511

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System