Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Tue, 18 Mar 2014 18:00:25 +0100

On 18.03.2014 17:30, Brian Bevins wrote:

The waveforms are soft records that have their buffers filled by

dedicated threads, which then post events to process the records.

I only see the slowdown when a client is connected to the waveforms.

Even with the waveform records processing normally, the "fast" records

update normally as long as no CA clients monitor the waveforms. I

interpreted this to mean that the CA traffic was the bottleneck, but

maybe I'm wrong.

Hmmm... another idea:

Please check that you have no database links that would pull "fast" and

"slow" records into the same lock set.

During record processing, waveforms are put in the CA send queue by

reference, while atomic data is put directly into the queue.

When the low-priority CA send thread later-on copies the data out of the

record into the network buffer, it has to lock the record. (It can just

copy from the queue for atomic data, which does not require locking.)

Possible effect: if your database has link connections that pull

waveform records and "fast" records into the same lock set, the "fast"

records might block while CA copies data from the waveforms.

Perfectly harmless looking things, like SDIS links pointing to the same

"disable" record, may easily pull far too many records into the same

lock set.

Making this kind of links ".CA" often helps by breaking up the lock sets

without affecting function.

~Ralph

On 03/18/14 12:23, Mark Rivers wrote:

Are you certain that it is the CA update of the waveform records that

is slowing it down, and not the record processing? if your waveform

records are using synchronous device support and they take a long

time to process that can slow down all other records. What type of

device support do your waveform records have, synchronous or

asynchronous?

Mark

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System