Experimental Physics and Industrial Control System
Hi Ralph,
Thanks for the reply.
On Wed, May 26, 2010 at 11:27 AM, Ralph Lange <[email protected]> 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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024