Re: DBE_PROPERTY events

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 8/29/24 06:20, Zimoch Dirk via Core-talk wrote:
> Hi everyone
>
> Today I came across some "strange" behavior of property monitors. A colleague
> found that 'camonitor -m p' gives him four times as many updates as a normal
> monitor on a certain record. Checking the record, I found that each time it
> receives it value from the hardware, it gets updates for the alarm limits as
> well which are stored in .LOLO .LOW .HIGH and .HIHI. They rarely ever change,
> but nevertheless, each update causes a DBE_PROPERTY event.
>
> Checking the EPICS base code, I found thus in dbPut():
>      /* If this field is a property (metadata) field,
>       * then post a property change event (even if the field
>       * didn't change).
>       */
>      if (precord->mlis.count && pfldDes->prop)
>          db_post_events(precord, NULL, DBE_PROPERTY);
>
> So this behavior is on purpose, but I wonder why.
This was an explicitly made technical shortcut to get this feature in.

dbCore has no mechanism for previous value tracking, with this instead being left
to individual record support to handle.  Doing otherwise would seem to require
keeping a uniform previous value for every field, or eg. somehow encoding an
association between value and previous value into the DBD.

At the time (2013) the cost of retrofitting such a feature seemed out of proportion
to wasting bytes on "a few" duplicate updates.  With ~10 years before the first
complaint, I think this judgement held up.  :)

Still, you are more than welcomed to improve the situation.


> The commit 6a6e527fc1 that
> introduced this code also explicitly states:
>
> Author: Michael Davidsaver <mdavidsaver at bnl.gov>
> Date:   Mon Nov 4 13:39:17 2013 -0500
>
>      post DBE_PROPERTY from dbPut()
>
>      All writes to a prop(YES) field result
>      in a monitor, even when the field value
>      doesn't change.
>
>
> Is this really the desired behavior for puts to property fields?
No, not desirable.  Merely tolerable.


> It definitely
> surprised me. The goal of DBE_PROPERTY was, to my understanding, to allow
> clients to monitor property changes with a (significantly) lower rate than value
> changes.
>
> Unfortunately, I am unable to find the corresponding merge request which may
> have contained some enlightening comments about the reasons.
https://urldefense.us/v3/__https://epics.anl.gov/core-talk/2013/msg00091.php__;!!G_uCfscf7eWS!dI4URKoOAuiudfJXu_7nNcSSLtV98-PE5Csj5O7kjQ6nXNZ2zd_8R_l4ksK9FHLPTKfXaNz3n5D_TH1nDdlqnnwhGA$ 

With this bread crumb...

https://urldefense.us/v3/__https://code.launchpad.net/*epics-core/epics-base/postdbrprop__;fg!!G_uCfscf7eWS!dI4URKoOAuiudfJXu_7nNcSSLtV98-PE5Csj5O7kjQ6nXNZ2zd_8R_l4ksK9FHLPTKfXaNz3n5D_TH1nDdm_Uz0TGQ$ 

https://urldefense.us/v3/__https://code.launchpad.net/*epics-core/epics-base/postdbrprop/*merge/197290__;fis!!G_uCfscf7eWS!dI4URKoOAuiudfJXu_7nNcSSLtV98-PE5Csj5O7kjQ6nXNZ2zd_8R_l4ksK9FHLPTKfXaNz3n5D_TH1nDdnv_IGdGQ$ 

I suppose "Like, merging..." is a bit brief ;)


> Do others think too that property events should only be sent on change or is the
> current behavior desired by everyone else?
>
> Implementing such behavior is of course a bit tricky as a before-after
> comparison (in dbPut only without changes to the records) needs to take
> different field types and possibly conversions into account. (Luckily properties
> can very likely be expected to be scalars for the foreseeable future, thus
> limiting the require amount of buffer space for comparison.)  I am willing to
> invest some effort into this, if nobody opposes such a change.
>
> Dirk