docs/results/fuel-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 fuel-os-odl_l2-nofeature-ha
   8 ============================================
   9
  10 .. toctree::
  11    :maxdepth: 2
  12
  13
  14 Details
  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 Between test dates, the average measurements for memory bandwidth vary between
 124 15.5 and 25.4 GB/s. Within each test run the results vary more, with a minimal
 125 BW of 9.7 GB/s and maximum of 29.5 GB/s on the totality.
 126 SLA set to 6 GB/s. The SLA value is used as a reference, it has not been
 127 defined by OPNFV.
 128
 129
 130 TC070
 131 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 132 on different blades are measured when increasing the amount of UDP flows sent
 133 between the VMs using pktgen as packet generator tool.
 134
 135 Round trip times and packet throughput between VMs can typically be affected by
 136 the amount of flows set up and result in higher RTT and less PPS throughput.
 137
 138 The RTT results are similar throughout the different test dates and runs at
 139 approx. 15 ms. Some test runs show an increase with many flows, in the range
 140 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 141 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 142 RTT results.
 143 In some test runs when running with less than approx. 10000 flows the PPS
 144 throughput is normally flatter compared to when running with more flows, after
 145 which the PPS throughput decreases. Around 20 percent decrease in the worst
 146 case. For the other test runs there is however no significant change to the PPS
 147 throughput when the number of flows are increased. In some test runs the PPS
 148 is also greater with 1000000 flows compared to other test runs where the PPS
 149 result is less with only 2 flows.
 150
 151 The average PPS throughput in the different runs varies between 414000 and
 152 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 153 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 154 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 155 for RTT results).
 156
 157 There are lost packets reported in most of the test runs. There is no observed
 158 correlation between the amount of flows and the amount of lost packets.
 159 The lost amount of packets normally range between 100 and 1000 per test run,
 160 but there are spikes in the range of 10000 lost packets as well, and even
 161 more in a rare cases.
 162
 163 Memory utilization statistics are collected during UDP flows sent between the
 164 VMs using pktgen as packet generator tool. The average measurements for memory
 165 utilization vary between 225MB to 246MB. The peak of memory utilization appears
 166 around 340MB.
 167
 168 TC071
 169 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 170 on different blades are measured when increasing the amount of UDP flows sent
 171 between the VMs using pktgen as packet generator tool.
 172
 173 Round trip times and packet throughput between VMs can typically be affected by
 174 the amount of flows set up and result in higher RTT and less PPS throughput.
 175
 176 The RTT results are similar throughout the different test dates and runs at
 177 approx. 15 ms. Some test runs show an increase with many flows, in the range
 178 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 179 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 180 RTT results.
 181 In some test runs when running with less than approx. 10000 flows the PPS
 182 throughput is normally flatter compared to when running with more flows, after
 183 which the PPS throughput decreases. Around 20 percent decrease in the worst
 184 case. For the other test runs there is however no significant change to the PPS
 185 throughput when the number of flows are increased. In some test runs the PPS
 186 is also greater with 1000000 flows compared to other test runs where the PPS
 187 result is less with only 2 flows.
 188
 189 The average PPS throughput in the different runs varies between 414000 and
 190 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 191 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 192 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 193 for RTT results).
 194
 195 There are lost packets reported in most of the test runs. There is no observed
 196 correlation between the amount of flows and the amount of lost packets.
 197 The lost amount of packets normally range between 100 and 1000 per test run,
 198 but there are spikes in the range of 10000 lost packets as well, and even
 199 more in a rare cases.
 200
 201 Cache utilization statistics are collected during UDP flows sent between the
 202 VMs using pktgen as packet generator tool. The average measurements for cache
 203 utilization vary between 205MB to 212MB.
 204
 205 TC072
 206 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 207 on different blades are measured when increasing the amount of UDP flows sent
 208 between the VMs using pktgen as packet generator tool.
 209
 210 Round trip times and packet throughput between VMs can typically be affected by
 211 the amount of flows set up and result in higher RTT and less PPS throughput.
 212
 213 The RTT results are similar throughout the different test dates and runs at
 214 approx. 15 ms. Some test runs show an increase with many flows, in the range
 215 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 216 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 217 RTT results.
 218 In some test runs when running with less than approx. 10000 flows the PPS
 219 throughput is normally flatter compared to when running with more flows, after
 220 which the PPS throughput decreases. Around 20 percent decrease in the worst
 221 case. For the other test runs there is however no significant change to the PPS
 222 throughput when the number of flows are increased. In some test runs the PPS
 223 is also greater with 1000000 flows compared to other test runs where the PPS
 224 result is less with only 2 flows.
 225
 226 The average PPS throughput in the different runs varies between 414000 and
 227 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 228 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 229 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 230 for RTT results).
 231
 232 There are lost packets reported in most of the test runs. There is no observed
 233 correlation between the amount of flows and the amount of lost packets.
 234 The lost amount of packets normally range between 100 and 1000 per test run,
 235 but there are spikes in the range of 10000 lost packets as well, and even
 236 more in a rare cases.
 237
 238 Network utilization statistics are collected during UDP flows sent between the
 239 VMs using pktgen as packet generator tool. Total number of packets received per
 240 second was average on 200 kpps and total number of packets transmitted per
 241 second was average on 600 kpps.
 242
 243 Detailed test results
 244 ---------------------
 245 The scenario was run on Ericsson POD2_ and LF POD2_ with:
 246 Fuel 9.0
 247 OpenStack Mitaka
 248 OpenVirtualSwitch 2.5.90
 249 OpenDayLight Beryllium
 250
 251 Rationale for decisions
 252 -----------------------
 253 Pass
 254
 255 Tests were successfully executed and metrics collected.
 256 No SLA was verified. To be decided on in next release of OPNFV.
 257
 258 Conclusions and recommendations
 259 -------------------------------
 260 The pktgen test configuration has a relatively large base effect on RTT in
 261 TC037 compared to TC002, where there is no background load at all. Approx.
 262 15 ms compared to approx. 0.5 ms, which is more than a 3000 percentage
 263 difference in RTT results.
 264 Especially RTT and throughput come out with better results than for instance
 265 the *fuel-os-nosdn-nofeature-ha* scenario does. The reason for this should
 266 probably be further analyzed and understood. Also of interest could be
 267 to make further analyzes to find patterns and reasons for lost traffic.
 268 Also of interest could be to see if there are continuous variations where
 269 some test cases stand out with better or worse results than the general test
 270 case.
 271