3.14.12 caget without -c always requests maximum element count

[Jeff Hill]

From Mark Rivers

I am trying to read a large array from a VME IOC using caget. The array is 500000 elements, 32-bit integers. EPICS_CA_MAX_ARRAY_BYTES is set to 2000000 on the IOC, which is “just large enough” to read the entire array. EPICS_CA_MAX_ARRAY_BYTES is set to 20000000 (10 times larger than large enough) on the Linux client.

The IOC is running 3.14.12.1.

Here is the output of caget from a Linux client with EPICS 3.14.10, 3.14.11, and 3.14.12.1 when requesting 499000 elements, (1000 fewer than maximum) which should fit in EPICS_CA_MAX_ARRAY_BYTES.

3.14.10:
corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.10/bin/linux-x86/caget -#499000 -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:03:37 CDT 2011
Tue Jun 7 17:03:38 CDT 2011

3.14.11:
corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.11/bin/linux-x86/caget -#499000 -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:03:55 CDT 2011
Tue Jun 7 17:03:56 CDT 2011

3.14.12.1:
corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.12.1/bin/linux-x86/caget -#499000 -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:04:07 CDT 2011
CA.Client.Exception...............................................
    Warning: "The requested data transfer is greater than available memory or EPICS_CA_MAX_ARRAY_BYTES"
    Context: "op=0, channel=SIS:3820:mca1, type=DBR_TIME_LONG, count=500000, ctx="server unable to load read (or subscription update) response into protocol buffer PV="SIS:3820:mca1" max bytes=2000024""
    Source File: ../getCopy.cpp line 92
    Current Time: Tue Jun 07 2011 17:04:07.629564143
..................................................................

So on 3.14.10 and 3.14.11 it works as expected, caget is requesting fewer than the number of bytes that EPICS_CA_MAX_ARRAY_BYTES will allow, and it succeeds. But it fails on 3.14.12.1. The error message says count=500000. Is it trying to read all 500000 rather than the number requested?

The same error happens on 3.14.12.1 even if I try to only read 100 elements:

corvette:mca/iocBoot/iocVxWorks>/usr/local/epics/base-3.14.12.1/bin/linux-x86/caget -#100 -w20 SIS:3820:mca1
CA.Client.Exception...............................................
    Warning: "The requested data transfer is greater than available memory or EPICS_CA_MAX_ARRAY_BYTES"
    Context: "op=0, channel=SIS:3820:mca1, type=DBR_TIME_LONG, count=500000, ctx="server unable to load read (or subscription update) response into protocol buffer PV="SIS:3820:mca1" max bytes=2000024""
    Source File: ../getCopy.cpp line 92
    Current Time: Tue Jun 07 2011 17:24:56.617989921
..................................................................

I then increased EPICS_CA_MAX_ARRAY_BYTES on the IOC to 2000200, i.e. 200 more than the theoretical minimum number. I then did a caget of the entire array, and it worked fine on all 3 versions of EPICS base.

corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.10/bin/linux-x86/caget -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:16:25 CDT 2011
Tue Jun 7 17:16:26 CDT 2011
corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.11/bin/linux-x86/caget -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:16:44 CDT 2011
Tue Jun 7 17:16:45 CDT 2011
corvette:mca/iocBoot/iocVxWorks>date ; /usr/local/epics/base-3.14.12.1/bin/linux-x86/caget -w20 SIS:3820:mca1 > temp.out ; date
Tue Jun 7 17:16:55 CDT 2011
Tue Jun 7 17:16:56 CDT 2011

So it looks like there is something wrong with 3.14.12.1 when EPICS_CA_MAX_ARRAY_BYTES is not large enough for the entire array, even when many fewer elements are being requested

[Till Straumann (strauman)]

I could confirm this behavior (3.14.12 soft-IOC on linux-x86_64), 3.14.8.2 and 3.14.12 client.
There are two issues:

1)
As of 3.14.12 the 'caget' program has changed (for reasons unknown to me; it rather seems a bug).
When you ask for a number of elements less than the full array count ( -# option) and do *not*
specify the 'callback' option (-c) then the 3.14.12 version of the program fetches the native count
of elements and just limits the printed number of elements. You can work around this by using -c.

2)
There is nothing wrong with EPICS_CA_MAX_ARRAY_BYTES but you must make sure that
you can accommodate the data you ask for. By default (unless you request an explicit format),
caget asks for the native number of items in the native representation (type) in DBR_TIME_xxx
format which means that in addition to the data, time-stamp and status information also are
transferred. If you just want the pure data then you can specify a format

export EPICS_CA_MAX_ARRAY_BYTES=2000000
caget -d LONG

HTH
-- Till

[Ralph Lange (ralph-lange)]

The changes for 3.14.12 were introduced as part of Michael Abbott's dynamic-array-branch.
"12095.1.3: Add autosizing array support for caget and camonitor"

[Ralph Lange (ralph-lange)]

The fix was trivial and has been committed and pushed to 3.14 and 3.15 branches.

Verified using:
3.14.11 (no dyn-array) and 3.14 (current) server and client on linux-x86_64, Wireshark to check network traffic.

[Andrew Johnson (anj)]

Hi Ralph,

On 2011-08-25 you wrote:
> The fix was trivial and has been committed and pushed to 3.14 and 3.15
> branches.

Thanks; I don't actually see it in the 3.15 branch yet, but it will get merged
when I next pull in the bug fixes from 3.14 anyway so you don't actually need
to commit it yourself. You may have seen that I've been busy in the 3.15
branch...

I'm hoping to merge a rebased version of the server-side-plugins branch too,
but it doesn't rebase easily because of Michael Abbott's changes in the 3.14
branch.

- Andrew
--
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

[Andrew Johnson (anj)]

Ralph,

This fix unfortunately broke a simple caget of an array:

tux% caget anjHost:aSubExample.A
anjHost:aSubExample.A *** CA error Invalid element count requested

If I undo the change that was committed, it works again:

tux% caget anjHost:aSubExample.A
anjHost:aSubExample.A 10 0 1 2 3 4 5 6 7 8 9

I'm reopening this bug.

- Andrew

[Andrew Johnson (anj)]

The attached patch backs out most of the changes made to caget.c in commit 12112 which were causing this problem and at least one other bug. This implements the support for variable length arrays correctly:

* ppv->nElems always holds the array count as reported by ca_element_count()
* ppv->reqElems is set differently if making a ca_get_callback()
* ppv->reqElems is adjusted by the callback routine to the actual array size received

It's easier to follow these changes by comparing the resulting code against rev 12111.

[Andrew Johnson (anj)]

This is a better fix which has now been committed, and linked from the R3.14.12 Known Problems page.