Changes between Version 1 and Version 2 of UfoCameraTest150422

Timestamp:

Apr 22, 2015, 8:51:45 PM (10 years ago)

Author:

Suren A. Chilingaryan

Comment:

--

UfoCameraTest150422

@@ -16 +16 @@
 }}}
 * 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]