Intro:

Types of input data:

• .shs files: created by the echotek card:
• Usually 5 Mhz bandwidth upshifted and downshifted bands
• processing usually uses a 4K fft
• .rdev files: Created by tamarras machine (mock box with tamarra's filters).
• bandwidth is evolving.. was 32 Mhz...
  

The different flavors of the clp processing programs are:

• clp - multi threaded fftw (Multiple threads doing 1 fft). This works on the .rdev data (circa 2011)
  
• clp1 - single threaded fftw, multiple ipps processed simultaneously (multiple threads) using rdev files.
  
• clp1shs - single threaded fftw, multiple ipps using echotek .shs files.
• As of 12jan12
• clp1shs is the most up to date. It works.
• clp1,clp need to have the bug fixes put into clp1shs backported to them.
  

clp -  multiThreaded fftw (top)

• 1 input thread to read 10 second blocks of data
  
• 1 inpProcessing thread to find clp data, multiply by conjugate of code, put into 1 large buf
• 1 fftProcessing thread. Processes the entire 10 second fft with 1 call to threaded fftw using N threads
• 1 power and accumulate thread.
• 1 output thread.

• Program is compiled to run on 64bit intel. The current fftw libs have been compiled on aserv11 but it's probably the same to use the libs in /usr/lib64  since fftw doesn't use sse4. The fftw libs were compiled with --sse
  

• Source: /share/megs/phil/svn/aosoft/src/clp/clp.c
• Binary: /pkg/aosoft/fedora4/x86_64/bin/clp1shs
  
• Scripts:/pkg/aosoft/common/bin/clpserv.sc --help for options
  

clp1 - single Threaded fftw, multi threaded processing.  (top)

• 1 input thread to input 10 sec blocks of  clp data and then pass it to processing thread.
• N processing threads. One for each 10 secs of data:
  
• Decode by multiply by code conjugate
• fftw single threaded 1 height at a time
• power and accumulate.
• output block when done.

• Program is compiled to run on 64bit intel. The current fftw libs have been compiled on aserv11 but it's probably the same to use the libs in /usr/lib64  since fftw doesn't use sse4.

• Source: /share/megs/phil/svn/aosoft/src/clp/clp1.c
• Binary: /pkg/aosoft/fedora4/x86_64/bin/clp1
• Scripts:source/clpaserv.sc --help for options

clp1shs - single Threaded fftw, multi threaded processing for .shs files.  (top)

• 1 input thread to input 10 sec blocks of  clp data and then pass it to processing thread.
• N processing threads. 1 for each 10 secs of data:
  
• Decode by multiply by code conjugate
• fftw single threaded 1 height at a time
• power and accumulate.
• output block when done.
• program was created from clp1. It has some buf fixes that need to be back ported to clp1.
  

• Source: /share/megs/phil/svn/aosoft/src/clp/clp1shs.c
• Binary: /pkg/aosoft/fedora4/x86_64/bin/clp1shs
• Scripts:/pkg/aosoft/common/bin/clp1shs.sc --help for options

Selecting the clp ipps for the .shs files.  (top)

• Search each ipp until a clp ipp is found
• accumulate the requested number of ipps or until an non-clp ipp is found
• If you have accumulated more that N ipps (i've set N to 100 ipps or 1 second) then output the accumulated block to  a file.
• go back to the top.

• Each program had a different length transmitter pulse:
• power: 13*4 = 52 usecs
• mracf: 308 usecs
• clp: 440 usecs
• topsd:500 usecs.
• 100 samples (20 usecs @5mhz) is averaged at various positions in the tx pulse.
  
• A threshold is set. To be a clp ipp the various positions must be above or below this threshold.
• 150 usecs: power > than threshold
• This gets rid of power profiles
• 430 usecs: power > than threshold
  
• This gets rid of mracf profiles.
• 490 usecs: power < threshold.
• This exluded topside.
• 5.57 usecs is added to all positions.
• This is the rise time for the tx signal in klystrons and filters.
• 5 usecs is subtracted from the 430 and 490 positions to stay away from the turn off edge.

• data was taken: 10secs mracf, 10 secs power, then 4*10 secs of clp.
• The clp runs should then last for 40 secs or 4000 ipps.
  
• the echotek tried to only output the clp data.
• The three frames on each page show the power at 150, 430, and 490 usecs in the tx pulse.
• page 1: full vertical and horizontal scale:
• Top: 150 usecs:
•  the dropout at the start is power.
  
• Around  ipp 8000 there was another mracf, power cycle visible
• Middle: 430 usecs
• An extra dropout is seen at ipp 4100. This must be a mracf ipp that got pass the echotek.
• bottom: 490 usecs. Not much here since no topside was run.
• The average value is 8e6 at 150 usecs and 6.5e6 at 430 usecs. This falloff is the droop in the transmitter pulse.
• Page 2: blowup vertical scale, full horizontal scale.
• 430usecs:
  
• 6e5 pwr counts during power profile
• 490usecs:
•  6e5 pwr counts during power profile
• 2e5 pwr counts during mracf.
• These are outside the transmitter pulse for these programs.
  
• I'm not sure what the blanking duration was .. i's guess 200 usecs ..
  
• for power profile: 52 + 200 + 25 means that blanking was over
• for mracf:  308+25 + 200 : blanking was just finishing.

Summary:

• I set the threshold to 1.5e6 power counts.
• You need to set the threshold high enough so that the Tsys values at 430 and 490 usecs for power and mracf don't end up looking like tx power.

Using rserv1: 48 core amd machine:  (top)

• The program uses a single reader and then multiple processing threads (one for each 10 second block).
• The input data is being read via nfs over a 1gb/sec ethernet link.
• 193Mbytes of data is input and then passed to each thread before it starts processing.
• The input data is read sequentially, it is not overlapped with a threads processing:
• wait for thread to be available
• input thread data
• start thread processing
• goto next thread
• Some tests run:  daeron to rserv1 showed about 100 mb/sec xfering 2gb files with 9mb blocks (via dd)
  

• Page 1:
  
• top:   number of accumulated ipps (10millisec each) in each block. Normally this is 1000 (10 seconds).
• middle: Wall clock spacing between clp blocks.
• If power, mracf, and clp are each run for 10 seconds, then the clp spacing will be 30 seconds.
• Bottom: Number of blocks each thread processed.
• This shows how well the process was spread between the 45 threads.
• If there a number of short blocks then some threads may finish early and do more blocks.
• Page 2: timing:
• Top: Wait time for each thread startup.
• The first 45 threads have no startup wait time.
• The 46th block must wait for the processing time (880 secs) before it can be started. This is the wait time.
• the wait time should have a spike every 45 block starts (approximately)
• 2ndFrame: Read time each block.
• The i/o time to read the 10 seconds (193Mbytes) of data.
  
• i tried some dd's from daeron to rserv1 of 2gb files. I was getting close to 100 mb/sec. So it should only take a few seconds to read the  data.
  
• If the datataking was writing to the   daeron disk at the same time things could go slower.
  
• This occurs before the thread can be dispatched to start it's processing.
• The data is read in blocks of 1 second.
• 3rdFrame: Thread processing and output time.
• The output times is usually very short (fractions of a second) since the thread completes the i/o after the data gets to the memory bufffers.
  
• the total time is the sum of this time and the read time for each block.
• 4thFrame: average time for 1 4K fft
• The average and rms is printed in the header.
• 5thFrame:
• the average time to compute power and accumulate 1 4K spectra.

 home_~phil