Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Wed, 21 Jul 1999 10:42:27 -0600

> I have a couple of naive questions about the time period between a
database
> field change and its transmission to ca clients monitoring the field.

> I gather a low priority thread does this job and that therefore this might
> have significant variation?

Yes, the CA server is one of the lowest priority activities in an EPICS
IOC. This ensures that database processing, which has a predictable load
on the system, is not disturbed by the network communication load for
external clients which is expected to vary.

> Is there a lower limit? I've seen reference to
> the EPICS "clock tick" of 1/60sec - is this the maximum rate that changes
> are transmitted via monitors?

When a record posts a monitor event a data structure is added to the
event queue belonging to the client which is subscribed for the particular
monitor event that is being posted. After adding the data structure to the
queue a semaphore is set. A low priority task is blocking on this semaphore,
and after all higher priority labor has completed, it drains
the monitor event queue. If the client is external to the IOC then the
monitor events are forwarded as network messages to the external client.
If the client is internal to the IOC then this low priority task calls
a call back function (subroutine) associated by the client with the monitor
event subscription when the corresponding event is removed from the
queue.

Since the above approach is based on semaphores and a consumer/producer
queuing system then the internal event propagation delay is based on the
load
presented by higher priority activities in the IOC, and on OS scheduling
delays. If the IOC is lightly loaded then the OS scheduling delays will
predominate and I would expect internal delays averaging in the range
of 30 -100 micro seconds.

When transporting messages over the network to an external client there
will also be additional additive propagation delays. These delays
tend to be in the range of 500 micro second to one milli second when a
light load is presented, but have no upward bound if the network is heavily
loaded, or the external client's CPU is heavily loaded.

There should not be any built-in 1/60 of a second delays. It turns
out that many vxWorks systems have a time tick interrupt that occurs at
60 Hz, and vxWorks semaphore timeouts are based on multiples of this
interval (1/60 of a second), but the internal monitor event propagation
delay should not be based on this interval.

> Do similar considerations apply for records
> using CA input links, e.g. wait records?

Records with external CA input links wait for monitor events from the
external CA servers to which the links are attached. Records with
internal CA input links wait for internally generated monitor events
which are scheduled through the "EV dbCaLink" task which is running
at priority below database processing, but above the CA server. The
"EV dbCaLink" is waiting on a semaphore associated with a monitor
event queue and is directly calling the event callback function installed
with the monitor event subscription by the EPICS database source code.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System