Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 24 Jul 2009 19:48:00 -0600

> But why should the gateway convert doubles to strings? A client that
> requests numeric arrays as strings instead of the native format 
> is quite stupid.

Continuing with that line of reasoning, the server _could_, for array 
sizes exceeding NNN elements, refuse to accept CA get/subscribe/put 
request specifying the clients external type to be a DBR_STRING.

PS: We have always intended to move more of the conversion to the 
client but there are some complications. For example the client 
library would need to subscribe for enum string table changes and 
cache the updates. Still needs to be done.

PPS: I am running a test right now and I see about a 15 sec camonitor
freeze when running catime fetching to type DBR_STRING when there
are 1000 elements in the array.

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

Message content: TSPA

> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: Friday, July 24, 2009 1:12 AM
> To: Jeff Hill
> Cc: 'Ralph Lange'; 'Ernest L. Williams Jr.'; 'Amedeo Perazzo'; 'Core-Talk'
> Subject: Re: epicsSnPrintf is very slow when converting string arrays in
> GDD's aitConvert.cc
> 
> At the moment, I have EPICS_CA_MAX_ARRAY_BYTES=4000000 on the gateway.
> 
> But I found that the gateway already became slow with about 10 arrays of
> 2000
> double each, processing with 10 Hertz. So it's probably not a question of
> the
> array length but of the total array elements per second.
> 
> But why should the gateway convert doubles to strings? A client that
> requests
> numeric arrays as strings instead of the native format is quite stupid.
> 
> Dirk
> 
> 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
> >
> >
> >
> 
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System