Re: Bug in ca_pend_event() ?

[hill@luke.atdiv.lanl.gov (Jeff Hill)]

Mark,

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>
> main()
> {
> 	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?
> 
>                                                     Cheers,
>                                                     Mark
> 
> ____________________________________________________________
> 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                       rivers@cars3.uchicago.edu (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 
be specified).
 

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.

Jeff

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	johill@lanl.gov
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107