Doc for Xreview by other test projects
[yardstick.git] / docs / results / os-odl_l2-nofeature-ha.rst
1 .. This work is licensed under a Creative Commons Attribution 4.0 International
2 .. License.
3 .. http://creativecommons.org/licenses/by/4.0
4
5
6 =======================================
7 Test Results for os-odl_l2-nofeature-ha
8 =======================================
9
10 .. toctree::
11    :maxdepth: 2
12
13
14 fuel
15 ====
16
17 .. _Grafana: http://testresults.opnfv.org/grafana/dashboard/db/yardstick-main
18 .. _POD2: https://wiki.opnfv.org/pharos?&#community_test_labs
19
20 Overview of test results
21 ------------------------
22
23 See Grafana_ for viewing test result metrics for each respective test case. It
24 is possible to chose which specific scenarios to look at, and then to zoom in
25 on the details of each run test scenario as well.
26
27 All of the test case results below are based on 4 scenario test
28 runs, each run on the Ericsson POD2_ or LF POD2_ between August 25 and 29 in
29 2016.
30
31 TC002
32 -----
33 The round-trip-time (RTT) between 2 VMs on different blades is measured using
34 ping. Most test run measurements result on average between 0.5 and 0.6 ms.
35 A few runs start with a 1 - 1.5 ms RTT spike (This could be because of normal ARP
36 handling). One test run has a greater RTT spike of 1.9 ms, which is the same
37 one with the 0.7 ms average. The other runs have no similar spike at all.
38 To be able to draw conclusions more runs should be made.
39 SLA set to 10 ms. The SLA value is used as a reference, it has not
40 been defined by OPNFV.
41
42 TC005
43 -----
44 The IO read bandwidth looks similar between different dates, with an
45 average between approx. 170 and 200 MB/s. Within each test run the results
46 vary, with a minimum 2 MB/s and maximum 838 MB/s on the totality. Most runs
47 have a minimum BW of 3 MB/s (two runs at 2 MB/s). The maximum BW varies more in
48 absolute numbers between the dates, between 617 and 838 MB/s.
49 SLA set to 400 MB/s. The SLA value is used as a reference, it has not been
50 defined by OPNFV.
51
52 TC010
53 -----
54 The measurements for memory latency are similar between test dates and result
55 in approx. 1.2 ns. The variations within each test run are similar, between
56 1.215 and 1.219 ns. One exception is February 16, where the average is 1.222
57 and varies between 1.22 and 1.28 ns.
58 SLA set to 30 ns. The SLA value is used as a reference, it has not been defined
59 by OPNFV.
60
61 TC011
62 -----
63 Packet delay variation between 2 VMs on different blades is measured using
64 Iperf3. On the first date the reported packet delay variation varies between
65 0.0025 and 0.011 ms, with an average delay variation of 0.0067 ms.
66 On the second date the delay variation varies between 0.002 and 0.006 ms, with
67 an average delay variation of 0.004 ms.
68
69 TC012
70 -----
71 Between test dates, the average measurements for memory bandwidth vary between
72 17.4 and 17.9 GB/s. Within each test run the results vary more, with a minimal
73 BW of 16.4 GB/s and maximum of 18.2 GB/s on the totality.
74 SLA set to 15 GB/s. The SLA value is used as a reference, it has not been
75 defined by OPNFV.
76
77 TC014
78 -----
79 The Unixbench processor test run results vary between scores 3080 and 3240,
80 one result each date. The average score on the total is 3150.
81 No SLA set.
82
83 TC037
84 -----
85 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
86 on different blades are measured when increasing the amount of UDP flows sent
87 between the VMs using pktgen as packet generator tool.
88
89 Round trip times and packet throughput between VMs can typically be affected by
90 the amount of flows set up and result in higher RTT and less PPS throughput.
91
92 The RTT results are similar throughout the different test dates and runs at
93 approx. 15 ms. Some test runs show an increase with many flows, in the range
94 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
95 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
96 RTT results.
97 In some test runs when running with less than approx. 10000 flows the PPS
98 throughput is normally flatter compared to when running with more flows, after
99 which the PPS throughput decreases. Around 20 percent decrease in the worst
100 case. For the other test runs there is however no significant change to the PPS
101 throughput when the number of flows are increased. In some test runs the PPS
102 is also greater with 1000000 flows compared to other test runs where the PPS
103 result is less with only 2 flows.
104
105 The average PPS throughput in the different runs varies between 414000 and
106 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
107 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
108 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
109 for RTT results).
110
111 There are lost packets reported in most of the test runs. There is no observed
112 correlation between the amount of flows and the amount of lost packets.
113 The lost amount of packets normally range between 100 and 1000 per test run,
114 but there are spikes in the range of 10000 lost packets as well, and even
115 more in a rare cases.
116
117 CPU utilization statistics are collected during UDP flows sent between the VMs
118 using pktgen as packet generator tool. The average measurements for CPU
119 utilization ratio vary between 1% to 2%. The peak of CPU utilization ratio
120 appears around 7%.
121
122 TC069
123 -----
124 Between test dates, the average measurements for memory bandwidth vary between
125 15.5 and 25.4 GB/s. Within each test run the results vary more, with a minimal
126 BW of 9.7 GB/s and maximum of 29.5 GB/s on the totality.
127 SLA set to 6 GB/s. The SLA value is used as a reference, it has not been
128 defined by OPNFV.
129
130 TC070
131 -----
132 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
133 on different blades are measured when increasing the amount of UDP flows sent
134 between the VMs using pktgen as packet generator tool.
135
136 Round trip times and packet throughput between VMs can typically be affected by
137 the amount of flows set up and result in higher RTT and less PPS throughput.
138
139 The RTT results are similar throughout the different test dates and runs at
140 approx. 15 ms. Some test runs show an increase with many flows, in the range
141 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
142 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
143 RTT results.
144 In some test runs when running with less than approx. 10000 flows the PPS
145 throughput is normally flatter compared to when running with more flows, after
146 which the PPS throughput decreases. Around 20 percent decrease in the worst
147 case. For the other test runs there is however no significant change to the PPS
148 throughput when the number of flows are increased. In some test runs the PPS
149 is also greater with 1000000 flows compared to other test runs where the PPS
150 result is less with only 2 flows.
151
152 The average PPS throughput in the different runs varies between 414000 and
153 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
154 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
155 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
156 for RTT results).
157
158 There are lost packets reported in most of the test runs. There is no observed
159 correlation between the amount of flows and the amount of lost packets.
160 The lost amount of packets normally range between 100 and 1000 per test run,
161 but there are spikes in the range of 10000 lost packets as well, and even
162 more in a rare cases.
163
164 Memory utilization statistics are collected during UDP flows sent between the
165 VMs using pktgen as packet generator tool. The average measurements for memory
166 utilization vary between 225MB to 246MB. The peak of memory utilization appears
167 around 340MB.
168
169 TC071
170 -----
171 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
172 on different blades are measured when increasing the amount of UDP flows sent
173 between the VMs using pktgen as packet generator tool.
174
175 Round trip times and packet throughput between VMs can typically be affected by
176 the amount of flows set up and result in higher RTT and less PPS throughput.
177
178 The RTT results are similar throughout the different test dates and runs at
179 approx. 15 ms. Some test runs show an increase with many flows, in the range
180 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
181 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
182 RTT results.
183 In some test runs when running with less than approx. 10000 flows the PPS
184 throughput is normally flatter compared to when running with more flows, after
185 which the PPS throughput decreases. Around 20 percent decrease in the worst
186 case. For the other test runs there is however no significant change to the PPS
187 throughput when the number of flows are increased. In some test runs the PPS
188 is also greater with 1000000 flows compared to other test runs where the PPS
189 result is less with only 2 flows.
190
191 The average PPS throughput in the different runs varies between 414000 and
192 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
193 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
194 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
195 for RTT results).
196
197 There are lost packets reported in most of the test runs. There is no observed
198 correlation between the amount of flows and the amount of lost packets.
199 The lost amount of packets normally range between 100 and 1000 per test run,
200 but there are spikes in the range of 10000 lost packets as well, and even
201 more in a rare cases.
202
203 Cache utilization statistics are collected during UDP flows sent between the
204 VMs using pktgen as packet generator tool. The average measurements for cache
205 utilization vary between 205MB to 212MB.
206
207 TC072
208 -----
209 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
210 on different blades are measured when increasing the amount of UDP flows sent
211 between the VMs using pktgen as packet generator tool.
212
213 Round trip times and packet throughput between VMs can typically be affected by
214 the amount of flows set up and result in higher RTT and less PPS throughput.
215
216 The RTT results are similar throughout the different test dates and runs at
217 approx. 15 ms. Some test runs show an increase with many flows, in the range
218 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
219 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
220 RTT results.
221 In some test runs when running with less than approx. 10000 flows the PPS
222 throughput is normally flatter compared to when running with more flows, after
223 which the PPS throughput decreases. Around 20 percent decrease in the worst
224 case. For the other test runs there is however no significant change to the PPS
225 throughput when the number of flows are increased. In some test runs the PPS
226 is also greater with 1000000 flows compared to other test runs where the PPS
227 result is less with only 2 flows.
228
229 The average PPS throughput in the different runs varies between 414000 and
230 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
231 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
232 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
233 for RTT results).
234
235 There are lost packets reported in most of the test runs. There is no observed
236 correlation between the amount of flows and the amount of lost packets.
237 The lost amount of packets normally range between 100 and 1000 per test run,
238 but there are spikes in the range of 10000 lost packets as well, and even
239 more in a rare cases.
240
241 Network utilization statistics are collected during UDP flows sent between the
242 VMs using pktgen as packet generator tool. Total number of packets received per
243 second was average on 200 kpps and total number of packets transmitted per
244 second was average on 600 kpps.
245
246 Detailed test results
247 ---------------------
248 The scenario was run on Ericsson POD2_ and LF POD2_ with:
249 Fuel 9.0
250 OpenStack Mitaka
251 OpenVirtualSwitch 2.5.90
252 OpenDayLight Beryllium
253
254 Rationale for decisions
255 -----------------------
256 Pass
257
258 Tests were successfully executed and metrics collected.
259 No SLA was verified. To be decided on in next release of OPNFV.
260
261 Conclusions and recommendations
262 -------------------------------
263 The pktgen test configuration has a relatively large base effect on RTT in
264 TC037 compared to TC002, where there is no background load at all. Approx.
265 15 ms compared to approx. 0.5 ms, which is more than a 3000 percentage
266 difference in RTT results.
267 Especially RTT and throughput come out with better results than for instance
268 the *fuel-os-nosdn-nofeature-ha* scenario does. The reason for this should
269 probably be further analyzed and understood. Also of interest could be
270 to make further analyzes to find patterns and reasons for lost traffic.
271 Also of interest could be to see if there are continuous variations where
272 some test cases stand out with better or worse results than the general test
273 case.
274