Re: DBE_PROPERTY events

[Zimoch Dirk via Core-talk <core-talk at aps.anl.gov>]

I have measured the performance and could not find any difference between the
original and my changes. On my PC, the dbPut function takes about 6 ms when no
monitors are send and 12 ms when 1 monior is sent. The comparison does not
change this. Any differences are negligible compared to noise of the
measurement.

I found minor a small penalty for calling dbFastPutConvertRoutine a second time
in case a difference was found compared to using memcpy.

I also tried to my own comparison and copy, bailing out of comparison at the
first different byte (what memcmp probably does as well) and copying only the
changes instead of using memcpy on the full field_size. The difference is too
tiny to see as the data is small (up to 16 bytes in case of EGU).

So for simplicity I use memcpy on the full field_size.


On Thu, 2024-08-29 at 14:27 +0200, Ralph Lange via Core-talk wrote:
> 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
> > 
> > 
> >