Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Fri, 05 Jan 2007 15:24:01 -0500

On Jan 5, 2007, at 15:06 , Kurt Biery wrote:

With EPICS Base R3.14.8.2, we have experimented with string and
waveform records and have noticed that messages are not always
delivered to monitor processes when the messages are quickly
written to the PV.

You're right.

I understand the reason is that only the most recent string or
waveform is cached on the server

side in order to preserve memory, because strings or waveforms can be
long

(well, EPICS strings are still fixed to char[40]).

Double or other 'small' types are queued up, so all your values

are eventually sent out,

but for strings, your N quick string updates end up as

a single monitor for the last string.
In a similar case (string record for log messages...) I ended up writing
then to my own queue, then a little sequence copied
those values slowly (<=10Hz) to the actual PV.
Problem 1: If you run out of memory because you queue up more than
you ever sent out, you're of course dead.
Problem 2: What is slow enough? When is it OK to send another value?
Problem 3: Even with 'double' or other data types which are queued up
on the server side, you can get into 'flow control' when
the client doesn't read fast enough.
There is no indication, no log message nor any other info
I'd know of that will tell you that you are or ever
were in flow control. You simply loose a few messages
without ever knowing about it.
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System