Conference turris::digital_unix

9383.0. "Alpha Server 4100 Strange Behavior" by TBC001::WONG () Thu Apr 03 1997 12:25

I just ran a benchmark on an AS4100 and found something hard to explain.
The user time reported by the time command changed by a fair bit everytime 
I rerun the test.  The job was heavily CPU bound.  The reported time could
go up and down without a particular pattern.  Below is an example of the
terminal output on two runs after the system was freshly booted:

a4100b> time ../pspml.x <ifdem
 get input, do error checking
 delta x,y,z =  0.3000000      0.3000000      0.3000000    
 Insufficient # of points per wavelength
 Wavelength =  0.6000000    
 Recommended max(deltax,deltaz) =  7.500000298023224E-002  Now   0.3000000    
 Warning!!! nmax =         250  is too small
 Recommended nmax =        1987
 initialize
 begin time loop   nmax=         250
          50
         100
         150
         200
         250
 
526.03u 0.54s 8:47 99% 0+489k 101+19io 11pf+0w
a4100b> time ../pspml.x <ifdem
 get input, do error checking
 delta x,y,z =  0.3000000      0.3000000      0.3000000    
 Insufficient # of points per wavelength
 Wavelength =  0.6000000    
 Recommended max(deltax,deltaz) =  7.500000298023224E-002  Now   0.3000000    
 Warning!!! nmax =         250  is too small
 Recommended nmax =        1987
 initialize
 begin time loop   nmax=         250
          50
         100
         150
         200
         250
 
606.17u 0.54s 10:06 99% 0+490k 0+19io 0pf+0w
a4100b>

Notice that the user time was over 15% longer on the second run.  I tried it
on a turbolaser and the variation on user time was never more than 3%.
The system has four 440Mhz cpu's (the program is single streamed so it used
only one cpu), 2 GB running Unix 3.2G.  Firmware versions tried include
4.8-5 and 4.8-6 with AlphaBios 5.28.

Furthermore, the AS4100 seemed to have a memory bandwidth problem as well.
When I ran two copies of the same program together, they could 
take up to 45% longer.  Is that normal???

Your comments and suggestions are most appreciated. 

    Addressing your final point first, Turbolaser never lets a single CPU
    get more than about 25% of the total available bandwidth.  Rawhide will
    let a single CPU get more like 50%.  Whether this is good or bad is in
    the eye of the beholder (I could argue it either way...)
    
    As to run-to-run variation, a possible cause is simply luck in board
    cache mapping.  15% variation from run to run is not uncommon in the
    SPEC suite.
    
    If you'd like to explore this further, IPROBE is your tool.