Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: alarm hook
From: "Liyu, Andrei" <liyua@ornl.gov>
To: Jeff Hill <johill@lanl.gov>, "Dalesio, Leo `Bob`" <dalesio@slac.stanford.edu>, Ralph Lange <Ralph.Lange@bessy.de>
Cc: Geoff Savage <savage@fnal.gov>, Matthias Clausen <Matthias.Clausen@desy.de>, Andrew Johnson <anj@aps.anl.gov>, EPICS core-talk <core-talk@aps.anl.gov>, Fritz Bartlett <bartlett@fnal.gov>
Date: 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:johill@lanl.gov] 
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


Navigate by Date:
Prev: RE: alarm hook Liyu, Andrei
Next: epics regression tests on AMD64 running RHEL Linux 4.0 Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: alarm hook Liyu, Andrei
Next: Re: seq debugger Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·