Experimental Physics and
Industrial Control System

"Denison, PN \(Peter\)" <[email protected]> · Fri, 4 May 2007 12:10:06 +0100

> 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