• fftw performance:
• 27sep09: summer1 (cpu L5420.. harpertown)
• 02aug11: aserv11 (cpu X5550 .. nehalem)
• dec11     : rserv1 ( running 45 clp threads simultaneously)
  
• Intel Performance Primitives (ipp) library
• 15aug11: fft times aserv11 using intel benchmark (plot of times)
• 18aug11: fft times aserv11 using  my bencmark (table of times)
• Code long pulse processing times.
  
• 05apr06: ntp time jumps on the wapps 2003-2006. What was causing them.
• 30mar06: Look at when ntpd on aeron lost sync 2003-2006
• 10oct05: Some linux kernels see no speed up when running 2 processes on a dual processor cpu
• 19apr05: wapp clock drifts when taking data.
• 19apr05: ntp time server drifts when wapps take data.

FFTW performance

cpu: summer1: (top)

• cpu Specs:
•  Intel(R) Xeon(R) CPU L5420  @ 2.50GHz (formerly harpertown)
  
• 6144 MB cache / quad core (12MB total).
  
• dual quad core
  
• memory: 32 GB;
  

• Software runs:
• threads of 1, 4,8  (it is an dual quad core machine)
• SSE of and on
• I think it was single precision.
  

fftw on cpu  aserv11: (top)

• cpu Specs:
•  Intel(R) Xeon(R) CPU X5550  @ 2.67GHz (formerly nehalem)
  
• 8192 KB cache / quad core
  
• dual quad core
  
• memory: 24 GB
• hyperthreading enabled.
  

• Software runs:
• threads of 1, 4,8 ,12, 16  (it is an dual quad core machine)
• SSE was used (even though the table says sse2). Since i think it was single precision (which uses sse).
  
• I think it was single precision (the binary linked to the single precision lib.

• multithreading doesn't look like it helps until you get to 16K xforms (at least for 4 threads).
• You need a long xform to use lots of threads.
• Using too many threads slows it down.
  

intel performance primitives (IPP) lib: (top)

15aug11 IPP ffttimes on aserv11 (.ps) (.pdf) using intel benchmark program ps_ipps.

• this is an 8 processor nehalem machine
• I tried running with 1,4,8,16 threads but the intel test program ps_ipps seemed to only use 1 thread.
• The runs with multiple threads did produce slightly different times which is why the graphs jump around a bit.
  
• ran 2^10 to 2^24 lengths
• floating point data
• in test program  used: auto, 1% timing accuracy, 10;24;+1

18aug11: IPP table of ffttimes on aserv11/adslinux using my test program

• I wrote an fftbenchmark (x101/intel/tests/fftbnch.c) to play with the ipp fft times.
• float, complex, not in place transform.
• loop N times using same input, output array.
• run on aserv11.
• I used ippSetNumThreads() to vary the number of threads used to compute a single fft.
  
• The number of threads actually used maxed out at 2 (even though i asked for more).
• Only lenghts 8192 -> 128K allowed for 2 threads. All other lengths only used 1 thread even if i asked for more
• on they sandybridge processor, only 1 thread was ever used to compute a single fft even if i called ippSetNumThreads(n) with n > 1.
  
• the numbers in the table are probably only accurate to a few %.
• The cpus used:
• aserv11
  
• nehalem dual quad core cpus.
  
• 2.67 Ghz
• adslinux
• sandybridge quad core (DELL 8300)
  
• 3.4 GHZ
• os suse 11.4 with kernel 2.6.37.6 . linux kernel  doesn't support avx until 2.6.30.
• Threading:
  
• setting nthreads > 1 never generated a second thread?
•  This may be in the intel ipps library?
• 
  

• IPP COMPLEX OUT OF PLACE FFT TIMES

  FFTlen	time usecs 1 thread		time usecs 2 threads 1 fft
  	aserv11	adslinux	aserv11	adslinux
  1K	3.4	1.4	-
  2K	7.6	3.3	-
  4K	17.3	8.4	-
  8K	37.4	18.8	26.9
  16K	89.0	44.6	55.3
  32K	193.	102.5	111.6
  64K	435.	231	234.
  128K	933.	487	496.
  256K	2296.	1153	-
  512K	5709	3290	-
  1024K	12391	8088	-
  2048K	26776	17580	-
  4096K	55970.	37458	-
  8192K	129655.	83112	-
  16384K	270900.	178718	-

  
  

10oct05: Some linux kernels see no speed up when running 2 processes on a dual processor cpu. (top)

    The idl routine (atmclp) processes the coded long process atm data. It was used to benchmark  some of the dual processor cpus at the observatory. The data set used was:

• 100 ipps  of 10 millisecs each (so 1 second of data).
• 1 usec baud, 500 usec transmitted pulse, 5 Mhz bandwidth.
• For each ipp the tx samples were complex conjugated and then used for decoding each height.
• 601 heights for each ipp. At each height:
• The data was decoded with the xmiter samples  (2500 samples/height)
• A 4K complex transform was done and then the power was accumulated.
• So 60100 4K transforms were done as well as the decoding and power accumulation.
• This was doubled  (120200) since it was a dual beam experiment.
• The data set was read into memory. This ended up taking about 40Mb of data (all the machines had lots of memory > 1gb)
• The fftw routine was used for the fft (rather than the idl version).
• The i/o took a small fraction of the total time (< 1%). top showed 100% cpu usage while running.
• idl 6.1 was used.

For the aolc computers you should spread the jobs out over multiple cpus rather than trying to run two of the same on the same cpu (until arun gets a chance to update the kernels).
 

 home_~phil