On Oct 20, 2005, at 18:01 , Andrew Johnson wrote:
* update on change in value
with relative and absolute deadbands,
each as a positive and negative limit.
E.g. update when value increases by >= 1% or descreases by <=0.5%.
EPICS V3 only has a single absolute deadband.
...
* update on archive related changes
which are designated relative and absolute deadbands,
again pos. & neg.,
and in addition a minimum update rate.
EPICS V3 only ADEL, no additional periodic update.
"Designated" by who? In V3 the ADEL and MDEL fields allows the DB
designer to set appropriate per-record deadbands; just allowing
every client to set its own deadband in the subscription request
doesn't provide any way for the DB designer to even hint what an
appropriate deadband might be, which could signficantly impact IOC
performance. Maybe that information doesn't belong in the database
at all, but I'm not convinced of that; I don't think we have all
the requirements for V4 deadbands specified yet.
What the requirements are is of course a fundamental question
and part of our current dilemma.
If we consider support for other systems like Tango a requirement,
then update rates and deadbands can be designated by each client.
Bob's "V4 Functional Specifications" presentation from the SLAC
EPICS meeting also included
"V4 Data Acquisition Capabilities: New subscription parameters:
rate limit, value changes (as before but also % change)".
So from that I'd conclude:
V4 and Tango support both require
deadbands for 'on change' updates designated by the subscribing client.
You're follow-up concerns are all valid,
but they are implementation details to be determined
once we know if per-client deadbands & rates are requirements.
As far as I understand, the outcome of the Archamps meeting is
that there's very little management support for V4 development
because of the impression that we've been designing pieces of
a neat implementation, but without sufficient agreement amongst
the developers and more important without requirements from customers.
So more than one 'plug' has been pulled and we're back to
use cases, then a 'client' API design from Cosylab, ...
-Kay
- References:
- alarm/severity Kay-Uwe Kasemir
- Re: alarm/severity Ralph Lange
- Re: alarm/severity Kay-Uwe Kasemir
- Re: alarm/severity Andrew Johnson
- Navigate by Date:
- Prev:
Re: [Fwd: Re: Link arrays / syntax] Benjamin Franksen
- Next:
Re: alarm/severity Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: alarm/severity Andrew Johnson
- Next:
Record Processing Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|