I dont think that this is a bug - see below.
> I have been working today on tracking down a puzzling difference in the
> performance of two of the "easy-to-use" channel access libraries, libLca (the
> old library from Ben-Chin Cha) and libEzca (the new library from the APS).
> libLca is 2-5 times faster than libEzca for many operations, while the
> underlying code is very similar.
> I finally isolated the problem to the following:
> libEzca makes an additional call to ca_pend_event(.00001) whenever any of
> its routines are called. This has a huge impact on performance, which is
> not intuitively obvious.
> To explore this further I wrote the world's simplest test program to call
> ca_pend_event. Here it is:
> /* This program tests the time required for a simple call to ca_pend_event() */
> #include <cadef.h>
> int i;
> for (i=0; i<1000; i++) ca_pend_event(.00001);
> I then ran this program with the Unix "time" command on a number of different
> arhcitectures. Here are the results:
> Hardware OS CPU time Elapsed time
> Sun Sparc2 SunOS 4.1.3 .12 10.1
> Sun LX SunOS 5.4 (Solaris) .40 0.4
> SGI Indigo 2 IRIX 5.3 .26 10.0
> DEC AXP 3000/400 Digital Unix .02 1.0
> DEC AXP 3000/300 VMS 6.1 .01 1.0
> There is a very curious pattern here: Each call to ca_pend_event seems to
> require exactly 10 msec on Sun4 and SGI, and 1 msec on Digital Unix and VMS,
> even less on Solaris. It seems to me that there is at the very least a gross
> inconsistency in the way ca_pend_event() works on these various architectures.
> Am I missing something in my understanding of how ca_pend_event() is supposed
> to work, or is there a serious problem here? I thought ca_pend_event() was
> supposed to wait no longer than the delay time argument?
> Mark Rivers (312) 702-2279 (office)
> CARS (312) 702-9951 (secretary)
> Univ. of Chicago (312) 702-5454 (FAX)
> 5640 S. Ellis Ave. (708) 922-0499 (home)
> Chicago, IL 60637 firstname.lastname@example.org (Internet)
I also ran some tests - see below. On some os the cost to schedule
a delay within select is substantial. If the requested delay is
less than or equal one microsecond then I force the delay to be
zero when I call select so that these os delays are avoided when a poll
is what is really desired. I admit that the use of 1 uS is somewhat arbitrary
here. The problem is that on efficient os and fast processors
fairly short delays may be appropriate. I picked 1 uS because
it was reasonable for the machines we use. As CPUs become faster
we will need to lower this threshold. The bottom line is that
if the application needs to poll then they should specify a very
small delay - say 1e-9 or 1e-12. Many applications are calling
ca_pend_event(xxxx) in order to flush the output queue. If they used
ca_flush_io() to perform this action then their code would be more
architecture and os independent (because a delay need not
Hardware OS Elapsed time ca_pend_event() delay
Sun Sparc2 SunOS 4.1.3 10 sec 1e-5
Sun Sparc2 SunOS 4.1.3 < .5 sec 1e-6
I ran "catime" and it reports 190 uS per call to ca_pend_event()
when a delay of 1e-9 is used.
PS: I probably should set this threshold to (1.0/CLOCKS_PER_SEC).
Since CLOCKS_PER_SEC is ansi this would be portable.
Jeffrey O. Hill Internet email@example.com
LANL MS H820 Voice 505 665 1831
Los Alamos, NM 87545 USA FAX 505 665 5107
- Re: Bug in ca_pend_event() ? Guy Jennings
- Navigate by Date:
Re: ?delay record Ned Arnold
Table Look-up and Array Processing Thomas Dean
- Navigate by Thread:
?delay record Matthias Clausen DESY -MKV2/KRYK-
Re: Bug in ca_pend_event() ? Guy Jennings