Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Thu, 23 Jul 2009 12:58:33 -0700

Hi Jeff,

Here is an example of some the large arrays we have running around at

SLAC --LCLS:

FEE system
-------

DIAG:FEE1:481:DISPLAYWF.NELM 262144

DIAG:FEE1:482:DISPLAYWF.NELM 262144

CAMR:FEE1:455:IMAGE.NELM 307200

E- system

---------------

YAGS:DMP1:500:IMAGE.NELM       1.44768e+06
CAMR:IN20:186:IMAGE.NELM       307200
==========================================================================================

By the way, why don't we suffer from these issues with the IOC core implementation of the CA Server (i.e. rsrv)?
Or maybe, there are some subtle issues with large arrays even for iocCore?

One of the work-arounds we are considering for the purposes of IOC-Load balancing is to use a softIOC
in front of the source IOC.  Then most of our CA clients would make a connection to the softIOC
for a subscription to large arrays such as camera images.
What do you think?

Thanks,
Ernest

Jeff Hill wrote:

Ø 0.000132 seconds per conversion - is epicsSnPrintf() really that slow?

To answer my own question; no. I just finished adding

cvtFastPerform.cpp to libCom/tests and it looks like double to string

conversion take more like 3 uSec worst case which is about 44 times

faster than calculated.

Nevertheless, I am curious. What is the largest array size being

communicated via the gateways at SLAC and at PSI? This might become a

big issue for arrays exceeding say one million elements (that are

converted to strings by the gateway).

Still bug hunting.

Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected] <mailto:[email protected]>
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107

Message content: TSPA

*From:* Jeff Hill [mailto:[email protected]]
*Sent:* Wednesday, July 22, 2009 6:13 PM

*To:* 'Dirk Zimoch'; 'Ralph Lange'; 'Ernest L. Williams Jr.'; 'Amedeo

Perazzo'

*Cc:* 'Core-Talk'

*Subject:* epicsSnPrintf is very slow when converting string arrays in

GDD's aitConvert.cc

All,

I have discovered that a PCAS hang can occur when clients are fetching

very large arrays as strings. Just to convert the number of elements

that fit in a very large EPICS_CA_MAX_ARRAY_SIZE buffer with

epicsSnPrintf can take a very long time. It appears that this required

about 33 seconds during testing with EPICS_CA_MAX_ARRAY_SIZE of

10,000,000. Based on that I calculate 33 / ( 10,000,000 /

MAX_STRING_SIZE ) is 0.000132 seconds per conversion. Is

epicsSnPrintf() really that slow?

The solution appears to be to use the cvtFast library where it is in

range in GDD’s aitConvert.cc. The cvtFast functions are a bit scary in

today’s world - because a buffer size isn’t passed in – BTW. The

current workaround is to just not use them for buffer sizes below some

threshold.

Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected] <mailto:[email protected]>
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107

Message content: TSPA

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System