Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 31 Jan 2018 19:18:43 +0100

On 01/31/2018 03:01 PM, Simon Reiter wrote:
> On 01/31/2018 01:04 PM, Benjamin Franksen wrote:
>> I have tried to reproduce your problem by simplifying it to the bare
>> essentials: three states that do nothing but announce themselves through
>> a PV (using your macro and parts of your enum definition) and then
>> (unconditionally) go to the next state, looping the whole process for 10
>> iterations. I camonitor the PV state_current and expect to get a
>> sequence of values 1 2 3 1 2 3 etc. With normal pvPut this indeed fails:
>>
>> franksen@tiber: ~ > camonitor state_current
>> state_current                  2018-01-31 12:54:53.663351 3
>> state_current                  2018-01-31 12:56:20.357273 1
>> state_current                  2018-01-31 12:56:20.357293 1
>> state_current                  2018-01-31 12:56:20.357348 2
>> state_current                  2018-01-31 12:56:20.357348 2
>> state_current                  2018-01-31 12:56:20.357418 3
>> state_current                  2018-01-31 12:56:20.357418 3
>>
>> The reason it fails is that the fire-and-forget pvPut commands are
>> issued in a very tight loop here; the server receives the next ca_put
>> message before it can act (process, issue monitor events) on the first.
>>
>> But with pvPut(pv_variable, SYNC) I get the expected
> Some more testing showed that the same IOC build for linux-x86_64 is
> running as expect on my machine.
> So there seem to be a problem running this on linux-ppc.

Interesting. That confirms my suspicion that this is a problem in base,
not the sequencer; my guess is that any fast enough sequence of ca_put
operations on the same PV exhibits this problem (on this architecture).

Just a blind guess: could it be something about fast mutexes / spin
locks and how these are implemented for linux-ppc? I am not using these
in the sequencer, but they are used inside EPICS base (they have been
introduced in 3.15 or 3.16).

Another guess: wasn't there a problem report regarding put_notify a
while ago? Perhaps this is related.

Do we have tests in base for CA clients? If so, it might be possible to
adapt such a test so that it rapidly issues ca_put calls (with callback)
to the same PV and then see if camonitor sees all the events it should see.

Another angle that could be involved: does the sequencer program run on
the same IOC that serves the PV or a different one?

(Sorry for the brainstorming)

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System