Experimental Physics and
Industrial Control System

Kazuro FURUKAWA <[email protected]> · Wed, 20 Dec 2006 22:20:12 +0900

Dear all, 

For Tru64unix...

>>> On Wed, 20 Dec 2006 08:49:44 JST,  Kazuro FURUKAWA <[email protected]> wrote;
> > I have asked Jeff Hill to comment on the change you're making to the 
> > src/ca/comBuf.h file - I don't see why this should be necessary if it's 
> > not needed on other architectures.  He hasn't responded yet though, and 
> > we won't commit that change without his agreement.
> > 
> > > Its test results are not optimal yet as in 
> > >   <URL:http://www-linac.kek.jp/jk/osf/base-3.14.9-pre2-test-osf.txt>
> > > But I believe they are minor. 
> > 
> > You can manually run the src/libCom/test/O.osf-alpha/epicsStdioTest and 
> > src/libCom/test/O.osf-alpha/epicsTimerTest programs to see what the 
> > errors are actually reporting.  The epicsStdioTest failures imply that 
> > your system's vsnprintf() routine doesn't return the correct value.  You 
> > can fix this by creating a src/libCom/osi/os/osf/osdStdio.c file (copy 
> > and modify the posix version) to correct the OS error
> 
> You are right.  vsnprintf() is provided by libc but the behavior 
> in counting of characters is different from other OS's by one.  
> Do you know any free implementation of vsnprintf(), maybe freeBSD?  
> I think I need to define vsprintf() locally for Tru64unix.  For 
> timer error over 0.5% is also strange.  Maybe because the machine 
> was overloaded like load of more than 10.  (But at the lower load 
> it still showed errors with older versions...)
> 
> comBuf change is strange to me as well.  I forgot why I needed in 
> 3.14.4.  I'll look in these today again. 

[1] comBuf.h
I've tried it again without comBuf.h modification.  And I've got 
the following error.  I've changed the compiler features like 
-std {gun,ansi,ms,arm} and they gave me the same results.  I don't 
know why the error occurs, and why my change cures the compilation. 

=====
cxx  -c           -D_OSF_SOURCE -DUNIX   -std gnu -pthread -ieee  -O            
-I. -I.. -I../../../include/os/osf -I../../../include         ../comQueSend.cpp 
cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
          variable "tmp" of incomplete type "WireAlias<const char *>".
          detected during:
            instantiation of "void WireSet(const T &, epicsUInt8 *) [with
                      T=const char *]" at line 191 of "../comBuf.h"
            instantiation of
                      "bool comBuf::push(const T &) [with T=const char *]" at
                      line 144 of "../comQueSend.h"
            instantiation of
                      "void comQueSend::push(const T &) [with T=const char *]"
                      at line 112 of "../comQueSend.cpp"
    WireAlias < T > tmp;
--------------------^
cxx: Warning: ../comQueSend.cpp, line 327: pointless comparison of unsigned
          integer with zero
    if ( INVALID_DB_REQ ( dataType ) ) {
---------^
cxx: Info: 1 error detected in the compilation of "../comQueSend.cpp".
=====

I've put the full compilation log with above error at 
<URL:http://www-linac.kek.jp/jk/osf/base-3.14.9pr2-make-osf-failed.log>

[2] snprintf()
It seems the definition of the return value is different on Tru64. 
It simply returns the length of the buffer.  The buffer contents 
are OK.  The part of the results is like this. 
=====
not ok  1 - epicsSnprintf(size=1) = 0
ok  2 - buffer = ''
ok  3 - length = 0
not ok  4 - epicsSnprintf(size=2) = 1
ok  5 - buffer = 'i'
ok  6 - length = 1
=====
The return value should be 46.  We may include a version of free 
snprintf() into the source tree, but... 

[3] timer
An example of the errore is like this. 
=====
./epicsTimerTest
1..33
# Testing timer accuracy
not ok  1 - percentError < messageThresh
# delay = 1.000000 s, error = -0.007792 s (0.8 %)
not ok  2 - percentError < messageThresh
# delay = 1.100000 s, error = -0.007204 s (0.7 %)
not ok  3 - percentError < messageThresh
# delay = 1.200000 s, error = -0.007592 s (0.6 %)
not ok  4 - percentError < messageThresh
# delay = 1.300000 s, error = -0.007981 s (0.6 %)
not ok  5 - percentError < messageThresh
# delay = 1.400000 s, error = -0.007393 s (0.5 %)
not ok  6 - percentError < messageThresh
# delay = 1.500000 s, error = -0.007781 s (0.5 %)
not ok  7 - percentError < messageThresh
# delay = 1.600000 s, error = -0.008170 s (0.5 %)
ok  8 - percentError < messageThresh
ok  9 - percentError < messageThresh
ok 10 - percentError < messageThresh
ok 11 - percentError < messageThresh
ok 12 - percentError < messageThresh
ok 13 - percentError < messageThresh
ok 14 - percentError < messageThresh
ok 15 - percentError < messageThresh
ok 16 - percentError < messageThresh
ok 17 - percentError < messageThresh
ok 18 - percentError < messageThresh
ok 19 - percentError < messageThresh
ok 20 - percentError < messageThresh
ok 21 - percentError < messageThresh
ok 22 - percentError < messageThresh
ok 23 - percentError < messageThresh
ok 24 - percentError < messageThresh
ok 25 - percentError < messageThresh
# average timer delay error -7.415040 ms
# Testing timer cancellation
# starting 25 timers
ok 26 - cancelVerify::expireCount == 0
ok 27 - cancelVerify::cancellCount == 0
# cancelling timers
ok 28 - cancelVerify::expireCount == 0
ok 29 - cancelVerify::cancellCount == nTimers
# waiting until after timers should have expired
ok 30 - cancelVerify::expireCount == 0
ok 31 - cancelVerify::cancellCount == nTimers
# Testing timer destruction in expire()
# starting 25 timers
# waiting until all timers should have expired
ok 32 - expireDestroVerify::destroyCount == nTimers
# Testing periodic timers
# starting 25 timers
# waiting until all timers should have expired
ok 33 - All timers expiring

    Results
    =======
       Tests: 33
      Passed: 26 = 78%
      Failed:  7 = 21%
=====

Without load, software with usleep() or setitimer() normally shows 
0-2 millisecond accuracy.  So the above discrepancies are large 
compared with my experiences.  We have 7 alpha machines at KEKB 
and Linac.  The numbers of processes are 200 to 600, and the load 
averages are 1 to 15.  The results do not change much between 
machines.  I don't know the origin of the errors. 

If we need to fix above errors, I'll look in them more.  Sorry 
for the quality of the patch. 

Cheers, Kazuro.  
-----
Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System