Experimental Physics and
Industrial Control System

"Liyu, Andrei" <[email protected]> · Wed, 28 Jun 2006 17:01:12 -0400

Jeff,

I absolutely agree with you (replacing the last update on the queue)
when we talk about data or universal interface.
Main goal of alarm subsystem is another. Of course, it is well if Alarm
subsystem handles all alarms. In another case I suppose operators and
IOC engineers are most interested in the order of coming alarms.

Thank you - Andrei.

-----Original Message-----
From: Jeff Hill [mailto:[email protected]] 
Sent: Thursday, June 22, 2006 12:53 PM
To: 'Dalesio, Leo `Bob`'; 'Ralph Lange'
Cc: 'Geoff Savage'; 'Matthias Clausen'; 'Andrew Johnson'; 'EPICS
core-talk'; 'Fritz Bartlett'; Liyu, Andrei
Subject: RE: alarm hook

In send-only-on-change subscription update systems one always needs some
per
subscription state that remembers that there was no queue space and that
we
were forced to discard a particular update. Later when queue space
becomes
available we will need to send an update for all subscriptions that are
not
current. In the CA server's event queue I handle this by replacing the
last
update on the queue for a particular subscription when the queue
saturates.

Based on private discussions with Geoff and Andrei I fear that they are
currently implementing an unreliable send-only-on-change subscription
update
event stream where alarm state change edges can be lost forever (if the
alarm queue saturates during an alarm burst). 

The original Fermilab alarm system is, I suspect, not a
send-only-on-change
system, but instead a send-periodically based system and therefore might
be
more likely to keep clients in sync.

Anyways that is my perception surrounding recent alarm hook
developments. I
am fearful that the EPICS community could be straying away from reliable
event transport, but feel free to realign my discernment of the
situation if
I am uninformed.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System