> -----Original Message-----
> From: Denison, PN (Peter) [mailto:[email protected]]
> Sent: Freitag, 4. Mai 2007 13:10
> 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.
Right! The EventTime driver takes care of this. The first thing is that
it does its registration at the end of iocInit (InitHookAtEnd) to let
the required hardware be initialized. Secondly the EventTime becomes
valid when the first sync event occurs. During this the actual time
provider is normally NTP time provider of generalTime.
> 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.
I have seen similar effect with drvTS but not with generalTime.
> Although it's not very elegant, the EventTime driver could just use
the
> "first-configured" EVG/EVR in the system.
It does exactly so. In the drvTS it was even less elegant as it only
could work with card number zero. The current version of EventTime takes
the first configured card irrespective of the card number.
Babak
- References:
- generalTime & EventTime Kalantari Babak
- Re: generalTime & EventTime Kay-Uwe Kasemir
- RE: generalTime & EventTime Thompson, David H.
- RE: generalTime & EventTime Denison, PN (Peter)
- Navigate by Date:
- Prev:
RE: generalTime & EventTime Thompson, David H.
- Next:
Bug in IOC "local" time Ralph Lange
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: generalTime & EventTime Thompson, David H.
- Next:
Bug in IOC "local" time Ralph Lange
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|