UVC Decode Performances

	A	B	C	D	E	F	G	I
1		A. No Async + usb_alloc_coherent (with my patch caching header data)	B. No Async memcpy + kmalloc	C. Async + usb_alloc_coherent (with Keiichi's patch caching header data)	D. Async memcpy + kmalloc	E. Async + kmalloc + manually dma_unmap/map for each packet	F. Async + kmalloc + manually dma_sync for each packet
2	frames	1121	949	874	870	928	927
3	packets	233471	243665	232786	231152	247476	246994
4	empty	44729	47804	45594	45390	34060	33997	Tomasz Figa 29th August 2018: Note that B and D are not directly comparable with E-F, because the former don't include the dma_map/unmap() done by the USB HCD framework. E should be equivalent to D, with USB HCD mapping bypassed and done directly in the UVC driver. F maps once and then does just a unidirectional sync before reading from the buffer.
5	errors	34801	2406	46	171	16	226
6	invalid	8017	1058	48	160	32	65
7	bytes	135668717	145563878	137989497	137406842	103315132	103017167
8	duration	32907	30939	29139	29036	30949	30938
9	URB-avg	140.252	43.817	250.912	71.222	90.551	91.344
10	URB-min	2.625	3.791	24.208	15.75	43.75	43.167
11	URB-max	660.625	212.042	1009.459	985.542	289.917	1142.167
12	header-avg	144.641	78.679	21.874	17.878	47.421	46.237
13	header-min	0	0	0	0	0	0
14	header-max	674.625	471.625	77.583	56.292	113.75	163.917	Tomasz Figa: 29th August 2018 F: Header Max: I wonder if we didn't just observe some random anomaly here, as we saw in Matwey's measurements earlier, because dma_unmap() is exactly a superset of dma_sync_single_for_cpu(). The difference in average close to measurement error might indeed confirm that.
15	latency-avg	10.073	10.155	33.723	32.068	58.389	58.43
16	latency-min	0.875	1.75	15.458	10.792	37.042	35.292
17	latency-max	26.541	28	172.375	946.459	253.459	1106.583
18	decode-avg	130.179	33.662	217.188	39.154	32.161	32.913
19	decode-min	0.875	1.75	4.084	1.458	2.041	2.334
20	decode-max	634.375	186.084	978.542	246.167	124.542	215.833
21	raw-decode	2.740 Gbits/s	14.201 Gbits/s	2.212 Gbits/s	12.491 Gbits/s	13.775 Gbits/s	13.510 Gbits/s
22	raw-URB	2.541 Gbits/s	10.883 Gbits/s	1.913 Gbits/s	6.870 Gbits/s	4.890 Gbits/s	4.847 Gbits/s	Kieran Bingham 28th June 2019: Re: F: Header Max - I've just seen the URB max is also large along with the latency-max. It was probably some delay in the USB layer that caused this spike
23	throughput	32.982 Mbits/s	37.638 Mbits/s	37.884 Mbits/s	37.858 Mbits/s	26.705 Mbits/s	26.638 Mbits/s
24	CPU usage	1.205779 %	0.266349 %	1.715060 %	0.304485 %	0.194948 %	0.198726 %
25
26				Tomasz Figa 7th June 2019: Doesn't the difference in throughput between the 6 tests suggest that the camera might have been capturing different contents (i.e. different compression ratio) or at different frame rates (i.e. different lighting conditions)? EDIT: Given the values of "frames" being similar, similar differences between the "duration" values and the big differences between "bytes" values, I'd say this is about the compression ratio (=== contents of the frames)?
27
28		Patch adding statistics
29
30
31
32
33				Kieran Bingham: 7th June 2019 I'm afraid we'd have to check the test process with Matwey/ Keiichi, I simply analysed the results he posted into this table. On that note, If these tests are using JPEG formats that could certainly cause content to affect data throughput - so it should be a fixed bitrate format used in the tests. Perhaps throwing some test code to control the number of frames captured, and then process the results might help too.
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100