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