Experimental Physics and
Industrial Control System

"Hu, Yong" <[email protected]> · Fri, 6 Jun 2014 11:24:51 +0000

Hi Andrew and Eric,

Thanks for sharing your opinions and ideas. I have different views about the change I have made on caget.c and other things:

1. "Having different clients behave differently seems like it’s going to cause a lot more problems than it solves.". I don't think the change on the command-line tool caget will cause any problem. Firstly, different CA clients are actually behaving differently depending on how we define "behavior", i.e. users may feel that EDM runs so fast and consumes little CPU and memory resources while having opposite feelings when using CSS; users don't need to think about the settings of EPICS_CA_MAX_ARRAY_BYTES if their site-specific CSS already has this configured to a very large number, but they need to configure EPICS_CA_MAX_ARRAY_BYTES when they use the command caget on Windows; etc. Secondly, my proposed change doesn't change the CA APIs. It doesn't change any existing EPICS_CA_MAX_ARRAY_BYTES settings such as the one in ~/.profile or /etc/profile.d. Keep in mind that caget(.c) is just a very convenient command-line tool. Once it is executed, it is done and it is gone. Thirdly bu!
 t not lastly, if users already set EPICS_CA_MAX_ARRAY_BYTES to a very large number, you will find that my change on caget.c does nothing on EPICS_CA_MAX_ARRAY_BYTES if you look through the code closely. The code only reconfigures EPICS_CA_MAX_ARRAY_BYTES if and only if the value of EPICS_CA_MAX_ARRAY_BYTES is not big enough to get the job done successfully. In short, the change on caget does not introduce any bad behavior, it is a complement to the great command-line tool caget, it makes caget more convenient and ease-of-use.  

2. "/etc/profile.d": you forget about the CA clients on Windows and Mac which doesn't have this thing. And sometimes it takes lots of effort to figure out how to configure EPICS_CA_MAX_ARRAY_BYTES on different Windows OSs.

3. I think it is very difficult to configure architecture-specific default settings. I saw some IOCs running linux-x86, but they have very limited memory.             

4. We are in a big data era. But we still keep the default EPICS_CA_MAX_ARRAY_BYTES to a low value at 16K bytes mainly because there are some tiny IOCs which have limited memory resource. I believe that most modern CA clients such as EDM, CSS, etc. should have have no problem with EPICS_CA_MAX_ARRAY_BYTES to tens of or even hundreds of Megabytes. How about the idea of creating another environment variable "EPICS_CAS_MAX_ARRAY_BYTES" with a default low value at 16K dedicated for CA server (IOC) and using EPICS_CA_MAX_ARRAY_BYTES with a default high value for CA client? The configurations of max_array_bytes on the client side and on the server side are independent, but currently we are using a single environment variable for two independent settings. Having said that, introducing a new environment variable may introduce other problems.    

5. Any progress on adding new parameters dynamically: https://blueprints.launchpad.net/epics-base/+spec/epicsconf? Will it solve the problems related to EPICS_CA_MAX_ARRAY_BYTES?

6. How about the idea of auto-configuring of EPICS_CA_MAX_ARRAY_BYTES on the server side?

Jeff, Ralph: you are the creators of CA APIs & catools. What do you think? 

Thanks,

Yong

________________________________________
From: [email protected] [[email protected]] on behalf of Andrew Johnson [[email protected]]
Sent: Thursday, June 05, 2014 5:09 PM
To: [email protected]
Subject: Re: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget

On 06/05/2014 03:56 PM, Eric Norum wrote:
> I’m not sure that this is a good idea.  Having different clients
> behave differently seems like it’s going to cause a lot more problems
> than it solves.

I agree; the best solution for most modern clients should be to set
EPICS_CA_MAX_ARRAY_BYTES to a very large number in a script that gets
installed into /etc/profile.d so everybody gets that setting without
having to think about it. About the only place where you would want to
avoid doing that would be in embedded IOCs that don't have virtual memory.

You could also put that big number in the configure/CONFIG_SITE_ENV file
of the copy of Base you use for client applications, as long as you use
a different version of Base without that setting for building your
embedded IOCs.

If someone wants to work out how to configure architecture-specific
default settings during the build of Base that might be an interesting
patch for future releases.

- Andrew

> On Jun 5, 2014, at 11:40 AM, Hu, Yong <[email protected]> wrote:
>
>> Hello All,
>>
>> I guess many EPICS users, especially beginners, had problems when
>> using the command "caget" to read large waveform data because they
>> forgot to reconfigure EPICS_CA_MAX_ARRAY_BYTES to a bigger number
>> or they didn't know how to configure this parameter. Now, this
>> problem seems to be fixed. See attached patch or .c file. I tested
>> it on Debian 6 / gcc 4.4.5 / base-3.14.12.2.
>>
>> I hope no users would use the command "camonitor" for big waveform
>> data. Auto-configuring of EPICS_CA_MAX_ARRAY_BYTES in camonitor
>> seems more complicated.
>>
>> Two years ago, there were discussions about automatically resizing
>> max_array_bytes:
>> http://www.aps.anl.gov/epics/tech-talk/2012/msg02136.php . I have
>> an idea about how to implement this on the ioc side (RSRV), but no
>> progress has been made yet. We just successfully completed NSLS-II
>> Storage Ring phase-I commissioning and our machine is in
>> maintenance. So, I have some free time to work on this again.
>>
>> All are welcomed to test the attached caget on Windows, Mac, and
>> other Linux distros. Any idea & suggestion is welcomed!
>>
>> Yong<caget.c-3.14.12.2.patch><caget.c>
>

--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System