Re: asyn IMAX data transfer exceeding EPICS_CA_MAX_ARRAY_BYTES

["Marco A. Barra Montevechi Filho via Tech-talk" <tech-talk at aps.anl.gov>]

(sending again as a copy because just now i realized i was replying in private. Sorry!)

Hello, Mark! Good morning.

Unfortunately it didnt. Im not sure if i understood the question correctly, but if i did, the answer is the following:

The IOC runs in a virtual machine (host) and is accessed by another virtual machine (client) which is configured via EPICS_CA_ADDR_LIST to search in the host's IP. This design works well here in LNLS, so it should not be the problem. EPICS_CA_MAX_ARRAY_BYTES is defined both in the host and in the client and set to the same values.
We also tried running caget in a jupyter notebook which also had EPICS_CA_MAX_ARRAY_BYTES defined on it as an environment variable. Neither strategy (runnning caget on the machine or in the notebook) worked.

For some reason, the error which i sent here earlier ("data transfer bigger than available memory or EPICS_CA_MAX_ARRAY_BYTES") is not showing up again. Instead, we get a direct segmentation fault that kills the IOC. Thus, i raise the following doubts:

-Does it makes sense to think of an IOC segmentation fault? Or is it just reporting a segmentation fault that actually happened inside the equipment controller and terminating for some reason? Does it makes sense to think that the data transfer is bigger than whats set in IMAX or in EPICS_CA_MAX_ARRAY_BYTES and so the IOC sigfaults and dies?
-If the answer to the first question is no, then does it makes sense to think of the IOC just propagating the segmentation fault message that comes from the equipment controller?
- if the answer to both previous questions is no, then should i only believe that sigfault comes from machine memory error?
-Is asyn prepared to deal with IMAX as big as 524288? (im not sure if this last question matters, though, since requesting large arrays of data with IMAX set to 256 also resulted in error sometimes).

If it helps, the field in which we are trying to caget is .BINP. .IFMT is configured to hybrid.

Thanks for your attention!

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: 16 March 2022 14:11
To: Siddons, David <siddons at bnl.gov>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>; Marco A. Barra Montevechi Filho <marco.filho at lnls.br>
Subject: Re: asyn IMAX data transfer exceeding EPICS_CA_MAX_ARRAY_BYTES

 

Did Pete’s suggestion fix the problem?

Sent from my iPhone

On Mar 15, 2022, at 9:42 AM, Siddons, David via Tech-talk <tech-talk at aps.anl.gov> wrote:



Hi Marco,

   Is EPICS_CA_MAX_ARRAY_BYTES set on both ends of the link?

Pete.

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Marco A. Barra Montevechi Filho via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, March 15, 2022 3:39 PM
To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: asyn IMAX data transfer exceeding EPICS_CA_MAX_ARRAY_BYTES

 

Hello all

Im debugging an EPICS asyn IOC which was working fine until now. The st.cmd of the IOC has a line which loaded asynRecord.db:

dbLoadRecords("$(ASYN)/db/asynRecord.db","P=$(DEV),R=asynEth,PORT=E873_ETH,ADDR=0,OMAX=256,IMAX=256")

and caput caget BL:H:EQ:asynEth.IFMT 1 (Hybrid)

caget BL:H:EQ:asynEth.BINP

in the IOC machine returned an array of numbers without any problem. However, it is recovering an array from a file much alrger than 256, so i suppose it just threw parts of the file away.
We wanted to get more of the file, so we raised IMAX to 350000 and defined the env variable EPICS_CA_MAX_ARRAY_BYTES=15728645. SO we got the error

caget MGN:A:E873:DIAG:A:asynEth.BINP

CA.Client.Exception...............................................

    Warning: "The requested data transfer is greater than available memory or EPICS_CA_MAX_ARRAY_BYTES"

    Context: "op=0, channel=MGN:A:E873:DIAG:A:asynEth.BINP, type=DBR_TIME_CHAR, count=16406, ctx="server unable to load read (or subscription update) response into protocol buffer PV="MGN:A:E873:DIAG:A:asynEth" max bytes=16408""

    Source File: ../getCopy.cpp line 92

    Current Time: Tue Mar 15 2022 16:32:11.936961493

..................................................................

Read operation timed out: some PV data was not read.

MGN:A:E873:DIAG:A:asynEth.BINP 350000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  (the zeroes continue)

So we tried lowering IMAX to 16406 but still the error persisted:

CA.Client.Exception...............................................

    Warning: "The requested data transfer is greater than available memory or EPICS_CA_MAX_ARRAY_BYTES"

    Context: "op=0, channel=MGN:A:E873:DIAG:A:asynEth.BINP, type=DBR_TIME_CHAR, count=16406, ctx="server unable to load read (or subscription update) response into protocol buffer PV="MGN:A:E873:DIAG:A:asynEth" max bytes=16408""

    Source File: ../getCopy.cpp line 92

    Current Time: Tue Mar 15 2022 16:32:11.936961493

..................................................................

Read operation timed out: some PV data was not read.

MGN:A:E873:DIAG:A:asynEth.BINP 16406 0 0 0 0 0 0

does anyone know if we are doing something wrong or forgetting something? I dont think memory should be the problem here... Where do these "max bytes=16408" come from?

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.