pva search period

[jacomago]

Is there a reason why MAX_SEARCH_PERIOD is hard coded in ChannelSearch.java? I'm wondering if it makes sense to be in the PVASettings.java instead.

It looks like from https://epics-base.github.io/pvxs/netconfig.html that pvxs does an exponential backoff, whereas from my initial reading that ChannelSearch does up to 30 seconds increasing in a second at a time.

Since the broadcasts can affect the network when this library is used in the Archiver Appliance I think it makes sense in the archiver to have a much longer MAX_SEARCH_PERIOD, and to have exponential backoff.

fyi @mdavidsaver @kasemir

[kasemir]

Does PVXS have an environment variable for the max search interval? Then use the same name.

The exponential search decay was a Channel Access idea. As far as I understand, Michael considered that too spiffy for no good reason. In PVXS client.cpp, there's "bucket" logic with a bucketInterval of 1 second and nBuckets = 30. Searches decay by moving down those buckets, with 30 secs as the max search period. That's what I copied into the Java implementation.

[kasemir]

Is there a reason why MAX_SEARCH_PERIOD is hard coded in ChannelSearch.java?

Because in PVXS, the corresponding setting https://github.com/epics-base/pvxs/blob/525c711ee56c87eaa8da97df478b510d35b41030/src/client.cpp#L44C1-L45C1 is

// number of buckets in the search ring
constexpr size_t nBuckets = 30u;

[kasemir]

The bucket approach has the advantage that you only need 1 timer, and searches tend to collect such that a single search message can then send all the searches in a bucket. Compare that to one timer per searched PV, and several single-PV searches are sent out a few milliseconds apart, causing overall more network traffic. I don't think the Archiver Appliance would want that.

[mdavidsaver]

From https://epics-base.github.io/pvxs/details.html#implementation-notes

• Client UDP search retry follows a linear backoff starting from 1 second and stepping to 30 seconds. cf. bucketInterval and nBuckets in client.cpp.
• To level UDP search traffic, search retry may delay a PV for an extra bucket if the difference in the number of PVs in the desired and subsequent buckets is too large.

This second "leveling" process is intended to make the search traffic for disconnected PVs become less "burst-y" over time. When doing this I was thinking of "large" clients like OPI or archivers. That said, I have not had much feedback on how successful this algorithm is.

https://github.com/epics-base/pvxs/blob/525c711ee56c87eaa8da97df478b510d35b41030/src/client.cpp#L1124-L1131

[kasemir]

I think the bucket mechanism is still a very good idea. Maybe allow updating the bucketInterval. Archive Appliance can set it to for example 10 to issue search after 10, 20, 30, ...seconds, eventually settling to once every 5 minutes.

[mdavidsaver]

Maybe allow updating the bucketInterval ...

This seems reasonable. So $EPICS_PVA_MAX_SEARCH_PERIOD, where the value is a single base 10 integer with implied units of seconds?

What would a reasonable minimum be? 10 seconds?

On the PVXS side, the API name could be pvxs::client::Config::maxSearchPeriod.

[jacomago]

That sounds good. Configurable is what I'm keen on. Some Archiver instances I expect long down IOCs (like a test/lab one) others have more stable set of IOCs.