Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES
From: Matt Newville <newville@cars.uchicago.edu>
To: Ralph Lange <Ralph.Lange@bessy.de>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Thu, 27 May 2010 20:25:01 -0500
Hi Ralph,

Thanks for the reply.

On Wed, May 26, 2010 at 11:27 AM, Ralph Lange <Ralph.Lange@bessy.de> wrote:
> Hi Matt,
>
> nope, it's the other way round:

Maybe I'm still not understanding completely because I don't see much
difference between your explanation and what I said,

> Neither the IOC nor the on-the-wire protocol limit the size of arrays to be
> transferred.

Yes, I understand this.  Obviously, we're talking about transferring
data arrays which already exist on real IOCs, on networks that can
transfer them.  The advice of "increase EPICS_CA_MAX_ARRAY_BYTES and
everything will work fine" implies (perhaps even demonstrates) that
the default value of EPICS_CA_MAX_ARRAY_BYTES is too small.

> CA server and client libraries internally use a carefully crafted mechanism
> of fixed-size buffers on free lists to avoid cluttering up the memory.

OK.

> This is especially important for servers, since IOCs may have limited
> memory and high availability requirements.

Are there IOCs that cannot have 16k of PV data values?  The value
cannot be set lower than 16k, so the limited-memory argument is a bit
suspect.  Anyway, the issue that keeps cropping up is not whether IOCs
can generate and serve the data, but whether clients can receive them.

> The largest fix-size buffers in that mechanism are by default 16384 bytes,
> which is more a historical than a technical value.

Is there really no technical reason for this value?  If it is only
historical, and it can be changed with a one-line fix to
base/configure/CONFIG_ENV, why not change it?  It appears to me that
the value is really used only in base/src/ca/cac.cpp (starting around
line 185), and there only to set a maximum data size.  There, you'll
see two interesting pieces of information:
  a) setting EPICS_CA_MAX_ARRAY_BYTES < 16384 (MAX_TCP) will result in
it being reset to 16384:
      so that one cannot set this to a number smaller than 16384  (so
much for allowing one to conserve
      resources on memory-starved systems!!)
  b) room for header information is added onto this value (apparently
contradicting an earlier description),
      up to 2*32 bytes.

> At some point, EPICS_CA_MAX_ARRAY_BYTES was introduced to allow setting the
> size for a free list of extra large buffers, thus allowing larger arrays to
> be transferred between clients and servers with matching configuration.

Well, what is 'extra large'?  I believe 'matching configurations' are
not important: the requirement is that the client must be able to
accept the size of the data from the server, so it is simply that the
value of EPICS_CA_MAX_ARRAY_BYTES for the client be 'large enough'

> So that configuration option was meant to *allow* for larger arrays, never
> intended to *restrict* the array size.

But restricting is exactly the effect that it does have for client
programs! The array already exists in some IOC, which is prepared to
transfer the data to any and all clients.  But unless a client
application knows how large an array is **BEFORE THE APPLICATION
BEGINS USING CA**, it cannot get the data.

> If you do not set the variable, the largest buffer will still have a size of
> 16384 bytes.

Again, why 2**14?  OK, 2**14 does not be as weird, small, or arbitrary
as the 40 character string length limit, but it sure seems weird,
small and arbitrary.

I've used the SSCAN record from synApps for many years.  With this
record, I frequently transfer 70+ arrays of 2000 floats (8000 bytes)
between clients and VME IOCs which are doing other tasks in addition
to the SSCAN record.  These IOCs would be the sorts of devices for
which one might worry about
performance. Yet, performance has not been a problem.  We use many MCA
records which are 2048 longs (so, 1/2 of EPICS_CA_MAX_ARRAY_BYTES),
and have no problems using many of these.  But if I define one MCA
record with 8192 longs, or if I set up a soft IOC on a workstation to
deliver Area Detector data EVERY client has to explicitly set
EPICS_CA_MAX_ARRAY_BYTES before attempting to get this data.

Is this the intended behavior?

Thanks,

--Matt

Replies:
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Andrew Johnson
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange
References:
labCA and EPICS_CA_MAX_ARRAY_BYTES John Dobbins
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES emmanuel_mayssat
RE: labCA and EPICS_CA_MAX_ARRAY_BYTES Mark Rivers
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Matt Newville
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange

Navigate by Date:
Prev: RE: building areaDetector firewire support on Windows Mark Rivers
Next: Re: Epics 3.14.8: faulty registrar statement in dbd causes memPartAlloc error on vxWorks Goetz Pfeiffer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange
Next: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·