== Performance ==

Measured with the setup from 10/04/2015 and a recent [https://github.com/ufo-kit/libuca/commit/4ec7d39fb87c0fe798212e03e1fb6441aa4d3296 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 [ticket:239]