Performance

Measured with the setup from 10/04/2015 and a recent ​libuca 4ec7d. The WG1220 signal generator was set to 200 Hz and (generally) the acquired number of frames to 1000.

• 10 bit mode. Software and external trigger modes only work up to 150 to 200 acquired frames, after that software and external modes utilize 0% and 100% CPU respectively

  $ uca-benchmark --num-runs=1 --num-frames=1000 ufo
  [  sync ] [     auto ]    59.26 Hz    474.07 MB/s
  

• 12 bit mode

  $ uca-benchmark --test-software --test-external --num-runs=1 --num-frames=1000 ufo
  [  sync ] [     auto ]    15.39 Hz    123.09 MB/s
  [  sync ] [ software ]    25.10 Hz    200.79 MB/s
  [  sync ] [ external ]    32.82 Hz    262.57 MB/s
  

• With both 10 and 12 bit modes, asynchronous streaming does not work work.

Analysis

• Failures

  The streaming fails due to the following.
  1) You can't first start streaming and then call pcilib_start. First
  camera should be started, then, streaming call is allowed. I have
  changed 'uca_ufo_camera_start_recording' on ipecamera4 to fix the
  procedure.
  2) On multicore, if the variable can be changed by other thread, you
  should declare it 'volatile' to avoid gcc optimizations. I have modified
  declaration of 'n_acquired_frames' in 'grab_frames_async' to
  	volatile guint n_acquired_frames = 0;
  
  
  I can't reproduce the problems with software triggering in 10bit mode on
  ipecamera4:
  ipecamera4:~ # uca-benchmark --num-runs=1 --num-frames=1000
  --test-software ufo
  [  sync ] [     auto ]    61.55 Hz    492.42 MB/s
  [  sync ] [ software ]    85.63 Hz    685.03 MB/s
  
  However, there is another bug in UCA which may cause it while switching
  between sync and async modes. It seems you never clear 'async' mode. So
  if after async test the sync test will be called, the grab_frames_sync
  will start asynchronous reading thread and will try to call grab
  synchronously as well. I.e. you need to clear asynchronous mode. I don't
  know how you planed to do it, so I have not fixed it.
  
  Also, I noticed that in "[ async ] [ software ]" and "[ async ] [
  external ]" modes, you actually calling sync variant. As I have not seen
  any software triggering code in grab_async, I guess this is just not
  implemented yet. But it is quite confused and better complain that mode
  is not implemented when give sync results instead.
  

• Low performance is actually due to frame corruption in the hardware explained in 239