Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 11 Jan 2007 17:50:12 -0700

Hello Kurt,

> Andrew mentioned that you've had
> plans for some time for an upgrade that would allow users to specify
> some amount of string or array buffering, and he suggested that we ask
> you about that (and cc: core-talk).

We have currently two code bases for CA servers in EPICS base. The "rsrv" CA
server that is still in use in the IOC, and the "portable" CA server used in
the CA gateway (proxy) and in other situations. This duplication has
persisted for too long and I am very anxious to get back to maintaining only
one server source code.

I am currently in the middle of retrofitting the interface between the
portable server and its underlying data store, but this has been delayed due
to preparations for EPICS R3.14.9. When I finish retrofitting the portable
server's interface I will be looking next at upgrading the event queue to
use a similar mechanism for interfacing with data as the portable server,
and a desire to specify complex application packaged data when posting
events to the event queue is part of our motivation for the retrofit. This
project is funded by LANSCE because LANSCE needs subscriptions specifying
beam flavors. 

As Andrew mentioned I am also definitely motivated to make the event queue's
data buffering model independent of the type and the complexity of the data,
and this is probably also synergistic with our requirements at LANSCE.

Of course it's easy to buffer complex data if we don't mind calling malloc
at a high duty factor. The problem becomes more complex when the design
constraints specify that we must try to buffer complex data w/o fragmenting
the memory of the embedded system and without loading the scan threads too
much in proportion to increasing client load (malloc is a very high overhead
call with its load increasing directly in proportion to memory
fragmentation). 

One possible approach is to push the memory allocation out to the
application specific event poster and place a reference counting smart
pointer in the client's event queue. That might be a less fragmenting
approach because the application specific event poster could use a free list
(instead of a raw call to malloc).

Another approach might be to just place the wire protocol directly on the
event queue, but this tends to increase a class of CPU load on the higher
priority record processing threads that is proportional to the number
clients. We have in the past been very careful about minimizing impact on
the record processing threads proportional to increasing client load.

I think that the idea of collaborating is a good one. We might even get what
we want in a shorter amount of time if we are able to find appropriate
interface boundaries between work done at different sites, and we are able
to properly specify constraints on the design of each independently
developed black box up front.

Jeff

> -----Original Message-----
> From: Kurt Biery [mailto:[email protected]]
> Sent: Wednesday, January 10, 2007 7:23 AM
> To: [email protected]
> Cc: [email protected]
> Subject: string and array buffering in soft IOCs
> 
> Hi Jeff,
> This note is a follow-up to my earlier posting on tech-talk regarding
> the buffering of string and array record data.  (Thanks for your reply!)
> 
> As I mentioned in my tech-talk message, we would like to use process
> variables in soft IOCs to pass string messages between processes in a
> DAQ system that we're designing.  I should have been more careful in
> that email, though, to mention that we're not suggesting that lots of
> large messages get buffered for long periods of time.  Rather, I was
> asking how one might configure EPICS to  gracefully handle (reasonably
> short) bursts of messages in a system in which the average rate of
> message production can easily be handled by the subscribers.  For
> example, the scenario that I presented in my tech-talk message which had
> a waveform record of 32 bytes being quickly updated 100 times and then
> left alone for a long time seemed like a scenario in which we might
> reasonably expect the 100 messages to be reliably delivered.  From the
> tech-talk responses that I received, though, it sounds like the graceful
> handling of bursts would be an enhancement rather than something that we
> can configure.
> 
> I described all of this to the NOvA DAQ group yesterday afternoon, and
> folks were supportive of learning more about the code changes that would
> be needed.  After the meeting, Margaret Votava and a few others in our
> group phoned Andrew Johnson to get his input on how we might most
> constructively make such changes.  Andrew mentioned that you've had
> plans for some time for an upgrade that would allow users to specify
> some amount of string or array buffering, and he suggested that we ask
> you about that (and cc: core-talk).  It's possible that our group could
> contribute to that development, and we would like to understand the
> scope.  Do you have time to talk about this at some point?
> Thanks,
> Kurt

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System