Re: alarm lag

[Andrew Johnson <anj@aps.anl.gov>]

Hi Matt,

On 2013-05-30 Pearson, Matthew R. wrote:
> Should it be up to the record to decide which fields to update alarm status
> for? For example, ai has VAL and RVAL. The RVAL field has the same issue.
> But having a monitor on RVAL, and wanting alarm updates on it, is probably
> something people want to do.

It is already, in that any fixes have to be made in the Record.c file anyway 
so different record types could come up with different semantics for monitor 
updates.  However the record has no control over what alarm info gets returned 
when you do a caget of one of the DBR-types that includes it, or for the first 
monitor update after subscribing to a channel; the server code automatically 
fills in the alarm data from the record's STAT and SEVR fields, and that can't 
be overridden by the record.

The solution I want to adopt for monitors should make updates more unified, 
but it does increase the network bandwidth used because we'll be sending out 
more monitor events.  This is the output I'd like to see from the example 
template:

tux2% camonitor anjHost:aiExample anjHost:aiExample.HIGH
anjHost:aiExample              2013-05-30 12:53:29.932526 4 LOW MINOR
anjHost:aiExample.HIGH         2013-05-30 12:53:29.932526 6 LOW MINOR
anjHost:aiExample              2013-05-30 12:53:30.932580 5  
anjHost:aiExample.HIGH         2013-05-30 12:53:30.932580 6  
anjHost:aiExample              2013-05-30 12:53:31.932526 6 HIGH MINOR
anjHost:aiExample.HIGH         2013-05-30 12:53:31.932526 6 HIGH MINOR
anjHost:aiExample              2013-05-30 12:53:32.932592 7 HIGH MINOR
anjHost:aiExample              2013-05-30 12:53:33.932526 8 HIHI MAJOR
anjHost:aiExample.HIGH         2013-05-30 12:53:33.932526 6 HIHI MAJOR
anjHost:aiExample              2013-05-30 12:53:34.932607 9 HIHI MAJOR
anjHost:aiExample              2013-05-30 12:53:35.932525 0 LOLO MAJOR
anjHost:aiExample.HIGH         2013-05-30 12:53:35.932525 6 LOLO MAJOR
anjHost:aiExample              2013-05-30 12:53:36.932587 1 LOLO MAJOR
anjHost:aiExample              2013-05-30 12:53:37.932526 2 LOLO MAJOR
anjHost:aiExample              2013-05-30 12:53:38.932585 3 LOW MINOR
anjHost:aiExample.HIGH         2013-05-30 12:53:38.932585 6 LOW MINOR
anjHost:aiExample              2013-05-30 12:53:39.932526 4 LOW MINOR


> Whereas having alarm updates for other fields might not mean much. However,
> one problem I see is with other records that might take these other fields
> as inputs. Would there be a problem with alarm propagation if, say, a calc
> record monitored a LOW or HIGH field in a ai record?

If you're using a link (DB or CA) with the alarm flags MS/MSS/MSI the alarm 
data are fetched properly from the data source using a DBR_STS_xxx type or its 
equivalent.  If we did develop the ability to provide per-field alarm data, 
the only problem would be where a database explicitly asks for the .STAT or 
.SEVR fields.  However I don't think it's particularly likely that we'd work 
on this ability, there are many more pressing features that need working on 
first IMHO.

- Andrew
-- 
It is difficult to get a man to understand something, when his salary
depends upon his not understanding it. -- Upton Sinclair