Re: generalTime & EventTime

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

Hi:

> 5. An API (e.g. a config command) will be provided to specify which
> event card (e.g. EVR/EVG) in a system is to be used by EventTime  
> driver.
> This should be called at the startup (by users). In principle we could
> implement the same method for NTP Time provider to specify which NTP
> server has to be used.

The API used to configure a time provider (NTP,  
MySpecialGPSReceiver, ...)
is of course a bit up to the implementor of that time provider.
NTP might look like this:

# Configure an NTP time provider to use given NTP server IP,
# and tell it to register with "generalTime" at priority 5
NTP_time_provider_config("123.45.24.8", 5)

# Configure an NTP time provider to use another  NTP server IP,
# and tell it to register with "generalTime" at priority 6
NTP_time_provider_config("123.45.24.7", 6)

For MySpecialGPSReceiver, it might look a bit different
MySpecialGPSReceiver_config(base address, poll interval, debug  
flag, ...., generalTime priority)

I thought the point was that the API on the general time side must  
include
a user arg.
When a time provider registers, it's not only
  generalTimeAddTimeProvider(my_get_time_routine, level)
but
  generalTimeAddTimeProvider(my_get_time_routine, my_user_arg, level)

That way, I can use that from within NTP_time_provider_config to
pass the specific IP address (structure with that IP plus whatever else
I need to remember) via my_user_arg.

-Kay


On May 2, 2007, at 10:54 , Kalantari Babak wrote:

> Hi Andrew,
>
> I have summarized our discussion in the last EPICS meeting at DESY
> regarding the generalTime/EventTime driver issues as the following:
>
> 1. Central part of generalTime which manages the time providers  
> will be
> moved to EPICS base. The time providers (VW, NTP, Event, etc.) are
> plugged in as drivers. The iocClockRegister.c will be integrated in  
> this
> central part and has to support all platforms (OS).
>
> 2. EventTime driver will completely rely on generalTime as an external
> time reference (e.g. at init or when the master clock wants to lock  
> to a
> reference time). It never contacts NTP server directly. To do so we  
> have
> to change the generalTime such that a time provider which is  
> correct can
> read generalTime clock by implicitly excluding itself from the list of
> time providers.
>
> 3. The generalTime API has to be changed in order to separate  
> GetEvent()
> and GetCurrent() registration because epicsTimeGetEvent() only makes
> sense for the event system.
>
> 4. In EventTime we should provide the users with possibility to  
> specify
> automatic/manual clock validation after clock failures. The manual  
> clock
> validation will be implemented by an "aoRecord" soft device support in
> which VAL field determines the tolerance of the difference between
> EventTime time and the reference time (which is given by generalTime,
> see point 2.) at the time of validating.
>
> 5. An API (e.g. a config command) will be provided to specify which
> event card (e.g. EVR/EVG) in a system is to be used by EventTime  
> driver.
> This should be called at the startup (by users). In principle we could
> implement the same method for NTP Time provider to specify which NTP
> server has to be used.
>
> 6. The OS time (e.g. vxWorks) should be the last time provider which
> always has to give a value for the time when all the other time
> providers are faulty.
>
> 7. This is more a question: the point from Stephanie Allison is still
> not clear to me; my understanding was that she is only interested in
> event time only when she has given a positive event number to TSE  
> field
> and otherwise (TSE=0) she is not interested in the time which is
> provided by event system. But this means to use two different time
> provider at the same time (priority problem?).
>
> 8. Finally we may change the name "generalTime" to something  
> different;
> maybe iocTime or iocTimeManager whatsoever.
>
> Please let me know your comments if something needs to be changed or
> something is missing.
> Sorry that the e-mail is a bit too long.
>
> Regards,
> Babak