Re: DBE_PROPERTY events

[Ralph Lange via Core-talk <core-talk at aps.anl.gov>]

The original assumption was that properties are changed rarely.

With that, getting an extra update when the property was written with no value change was a possible tiny network bandwidth overhead compared to the added complexity and performance hit of comparing all values before writing them.

I would see your suggested change as an improvement.

It will probably mostly apply to "intelligent" servers like PLCs below the IOC (connected by, say, StreamDevice or S7PLC or OPCUA), where the low-level controller often has a pretty complete set of what would become properties of a value. For now, these have to be read as separate values and written to the properties through database gymnastics - which greatly blows up the controller interface and EPICS databases. (On the other hand, this also allows updating on change, avoiding the effects that you describe.)

Generally, I'd be in favor.

Please measure performance change.

Cheers,

~Ralph

On Thu, 29 Aug 2024 at 12:21, Zimoch Dirk via Core-talk <core-talk at aps.anl.gov> 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. 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? 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.

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