SCAN vs MONITOR

Both SCAN and MONITOR use CA monitors, but they differ in how samples are buffered.

MONITOR estimates the number of samples based on the PV’s sampling period, allocates a buffer to hold that many samples, and fills it up. The buffer capacity is computed as:

int buffer_capacity = ((int) Math.round(Math.max((write_period/pvSamplingPeriod)*sampleBufferCapacityAdjustment, 1.0))) + 1;

  • pvSamplingPeriod — the sampling_period from the PV’s PVTypeInfo

  • write_period — the engine’s write period from archappl.properties (secondsToBuffer); defaults to 10 seconds

  • sampleBufferCapacityAdjustment — a system-wide buffer-size adjustment set in archappl.properties

The engine flushes all channel buffers in parallel using Java 21 virtual threads, so write_period no longer needs to be sized around how long sequential writes take. The tradeoffs are now:

  • Buffer memory: shorter period = smaller per-PV buffers = less JVM heap.

  • File I/O frequency: shorter period = more file open/write/close operations per second across all channels. Reduce cautiously on NFS or shared SAN storage.

  • STS data latency: shorter period = data appears in the short-term store sooner.

The engine metrics page exposes an “Equivalent sequential I/O load (%)” value that shows how loaded storage would be under the old sequential model. If that figure is well below 100%, the write period can safely be reduced.

For example, if write_period is 10 seconds and pvSamplingPeriod is 1 second, the buffer holds 11 samples. For a PV changing faster than 1 Hz, you will see 11 samples, a gap where the buffer overflows, then 11 more samples on the next buffer switch.

SCAN updates one slot at whatever rate is sent from the IOC, then a separate thread reads that slot every pvSamplingPeriod seconds and writes it to the buffer. This gives exactly one sample per pvSamplingPeriod regardless of the IOC update rate, at the cost of potentially missing intermediate values.