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 apex
  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 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 runs, each run
  28 on the LF POD1_ between September 14 and 17 in 2016.
  29
  30 TC002
  31 -----
  32 The round-trip-time (RTT) between 2 VMs on different blades is measured using
  33 ping. Most test run measurements result on average between 0.49 ms and 0.60 ms.
  34 Only one test run has reached greatest RTT spike of 0.93 ms. Meanwhile, the
  35 smallest network latency is 0.33 ms, which is obtained on Sep. 14th.
  36 SLA set to be 10 ms. The SLA value is used as a reference, it has not been
  37 defined by OPNFV.
  38
  39 TC005
  40 -----
  41 The IO read bandwidth actually refers to the storage throughput, which is
  42 measured by fio and the greatest IO read bandwidth of the four runs is 416
  43 MB/s. The IO read bandwidth of all four runs looks similar, with an average
  44 between 128 and 131 MB/s. One of the runs has a minimum BW of 497 KB/s. The SLA
  45 of read bandwidth sets to be 400 MB/s, which is used as a reference, and it has
  46 not been defined by OPNFV.
  47
  48 The results of storage IOPS for the four runs look similar with each other. The
  49 IO read times per second of the four test runs have an average value at 1k per
  50 second, and meanwhile, the minimum result is only 45 times per second.
  51
  52 TC010
  53 -----
  54 The tool we use to measure memory read latency is lmbench, which is a series of
  55 micro benchmarks intended to measure basic operating system and hardware system
  56 metrics. The memory read latency of the four runs is between 1.0859 ns and
  57 1.0869 ns on average. The variations within each test run are quite different,
  58 some vary from a large range and others have a small change. For example, the
  59 largest change is on September 14th, the memory read latency of which is ranging
  60 from 1.091 ns to 1.086 ns. However.
  61 The SLA sets to be 30 ns. The SLA value is used as a reference, it has not been
  62 defined by OPNFV.
  63
  64 TC011
  65 -----
  66 Packet delay variation between 2 VMs on different blades is measured using
  67 Iperf3. On the first two test runs the reported packet delay variation varies between
  68 0.0037 and 0.0740 ms, with an average delay variation between 0.0096 ms and 0.0321.
  69 On the second date the delay variation varies between 0.0063 and 0.0096 ms, with
  70 an average delay variation of 0.0124 - 0.0141 ms.
  71
  72 TC012
  73 -----
  74 Lmbench is also used to measure the memory read and write bandwidth, in which
  75 we use bw_mem to obtain the results. Among the four test runs, the trend of
  76 three memory bandwidth almost look similar, which all have a narrow range, and
  77 the average result is 19.88 GB/s. Here SLA set to be 15 GB/s. The SLA value is
  78 used as a reference, it has not been defined by OPNFV.
  79
  80 TC014
  81 -----
  82 The Unixbench is used to evaluate the IaaS processing speed with regards to
  83 score of single cpu running and parallel running. It can be seen from the
  84 dashboard that the processing test results vary from scores 3754k to 3831k, and
  85 there is only one result one date. No SLA set.
  86
  87 TC037
  88 -----
  89 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
  90 on different blades are measured when increasing the amount of UDP flows sent
  91 between the VMs using pktgen as packet generator tool.
  92
  93 Round trip times and packet throughput between VMs can typically be affected by
  94 the amount of flows set up and result in higher RTT and less PPS throughput.
  95
  96 The mean packet throughput of the four test runs is between 307.3 kpps and
  97 447.1 kpps, of which the result of the third run is the highest. The RTT
  98 results of all the test runs keep flat at approx. 15 ms. It is obvious that the
  99 PPS results are not as consistent as the RTT results.
 100
 101 The No. flows of the four test runs are 240 k on average and the PPS results
 102 look a little waved since the largest packet throughput is 418.1 kpps and the
 103 minimum throughput is 326.5 kpps respectively.
 104
 105 There are no errors of packets received in the four runs, but there are still
 106 lost packets in all the test runs. The RTT values obtained by ping of the four
 107 runs have the similar average vaue, that is approx. 15 ms.
 108
 109 CPU load is measured by mpstat, and CPU load of the four test runs seem a
 110 little similar, since the minimum value and the peak of CPU load is between 0
 111 percent and nine percent respectively. And the best result is obtained on Sep.
 112 1, with an CPU load of nine percent. But on the whole, the CPU load is very
 113 poor, since the average value is quite small.
 114
 115 TC069
 116 -----
 117 With the block size changing from 1 kb to 512 kb, the memory write bandwidth
 118 tends to become larger first and then smaller within every run test, which
 119 rangs from 28.2 GB/s to 29.5 GB/s and then to 29.2 GB/s on average. Since the
 120 test id is one, it is that only the INT memory write bandwidth is tested. On
 121 the whole, when the block size is 2 kb or 16 kb, the memory write bandwidth
 122 look similar with a minimal BW of 25.8 GB/s and peak value of 28.3 GB/s. And
 123 then with the block size becoming larger, the memory write bandwidth tends to
 124 decrease. SLA sets to be 7 GB/s. The SLA value is used as a reference, it has
 125 not been defined by OPNFV.
 126
 127 TC070
 128 -----
 129 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 130 on different blades are measured when increasing the amount of UDP flows sent
 131 between the VMs using pktgen as packet generator tool.
 132
 133 Round trip times and packet throughput between VMs can typically be affected by
 134 the amount of flows set up and result in higher RTT and less PPS throughput.
 135
 136 The network latency is measured by ping, and the results of the four test runs
 137 look similar with each other, and within these test runs, the maximum RTT can
 138 reach 39 ms and the average RTT is usually approx. 15 ms. The network latency
 139 tested on Sep. 1 and Sep. 8 have a peak latency of 39 ms. But on the whole,
 140 the average RTTs of the five runs keep flat and the network latency is
 141 relatively short.
 142
 143 Memory utilization is measured by free, which can display amount of free and
 144 used memory in the system. The largest amount of used memory is 267 MiB for the
 145 four runs. In general, the four test runs have very large memory utilization,
 146 which can reach 257 MiB on average. On the other hand, for the mean free memory,
 147 the four test runs have the similar trend with that of the mean used memory.
 148 In general, the mean free memory change from 233 MiB to 241 MiB.
 149
 150 Packet throughput and packet loss can be measured by pktgen, which is a tool
 151 in the network for generating traffic loads for network experiments. The mean
 152 packet throughput of the four test runs seem quite different, ranging from
 153 305.3 kpps to 447.1 kpps. The average number of flows in these tests is
 154 240000, and each run has a minimum number of flows of 2 and a maximum number
 155 of flows of 1.001 Mil. At the same time, the corresponding average packet
 156 throughput is between 354.4 kpps and 381.8 kpps. In summary, the PPS results
 157 seem consistent. Within each test run of the four runs, when number of flows
 158 becomes larger, the packet throughput seems not larger at the same time.
 159
 160 TC071
 161 -----
 162 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 163 on different blades are measured when increasing the amount of UDP flows sent
 164 between the VMs using pktgen as packet generator tool.
 165
 166 Round trip times and packet throughput between VMs can typically be affected by
 167 the amount of flows set up and result in higher RTT and less PPS throughput.
 168
 169 The network latency is measured by ping, and the results of the four test runs
 170 look similar with each other. Within each test run, the maximum RTT is only 42
 171 ms and the average RTT is usually approx. 15 ms. On the whole, the average
 172 RTTs of the four runs keep stable and the network latency is relatively small.
 173
 174 Cache utilization is measured by cachestat, which can display size of cache and
 175 buffer in the system. Cache utilization statistics are collected during UDP
 176 flows sent between the VMs using pktgen as packet generator tool. The largest
 177 cache size is 212 MiB, which is same for the four runs, and the smallest cache
 178 size is 75 MiB. On the whole, the average cache size of the four runs look the
 179 same and is between 197 MiB and 211 MiB. Meanwhile, the tread of the buffer
 180 size keep flat, since they have a minimum value of 7 MiB and a maximum value of
 181 8 MiB, with an average value of about 7.9 MiB.
 182
 183 Packet throughput can be measured by pktgen, which is a tool in the network for
 184 generating traffic loads for network experiments. The mean packet throughput of
 185 the four test runs differ from 354.4 kpps to 381.8 kpps. The average number of
 186 flows in these tests is 240k, and each run has a minimum number of flows of 2
 187 and a maximum number of flows of 1.001 Mil. At the same time, the corresponding
 188 packet throughput differ between 305.3 kpps to 447.1 kpps. Within each test run
 189 of the four runs, when number of flows becomes larger, the packet throughput
 190 seems not larger in the meantime.
 191
 192 TC072
 193 -----
 194 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 195 on different blades are measured when increasing the amount of UDP flows sent
 196 between the VMs using pktgen as packet generator tool.
 197
 198 Round trip times and packet throughput between VMs can typically be affected by
 199 the amount of flows set up and result in higher RTT and less PPS throughput.
 200
 201 The RTT results are similar throughout the different test dates and runs
 202 between 0 ms and 42 ms with an average leatency of less than 15 ms. The PPS
 203 results are not as consistent as the RTT results, for the mean packet
 204 throughput of the four runs differ from 354.4 kpps to 381.8 kpps.
 205
 206 Network utilization is measured by sar, that is system activity reporter, which
 207 can display the average statistics for the time since the system was started.
 208 Network utilization statistics are collected during UDP flows sent between the
 209 VMs using pktgen as packet generator tool. The largest total number of packets
 210 transmitted per second look similar for three test runs, whose values change a
 211 lot from 10 pps to 501 kpps. While results of the rest test run seem the same
 212 and keep stable with the average number of packets transmitted per second of 10
 213 pps. However, the total number of packets received per second of the four runs
 214 look similar, which have a large wide range of 2 pps to 815 kpps.
 215
 216 In some test runs when running with less than approx. 251000 flows the PPS
 217 throughput is normally flatter compared to when running with more flows, after
 218 which the PPS throughput decreases. For the other test runs there is however no
 219 significant change to the PPS throughput when the number of flows are
 220 increased. In some test runs the PPS is also greater with 251000 flows
 221 compared to other test runs where the PPS result is less with only 2 flows.
 222
 223 There are lost packets reported in most of the test runs. There is no observed
 224 correlation between the amount of flows and the amount of lost packets.
 225 The lost amount of packets normally differs a lot per test run.
 226
 227 Detailed test results
 228 ---------------------
 229 The scenario was run on LF POD1_ with:
 230 Apex
 231 OpenStack Mitaka
 232 OpenVirtualSwitch 2.5.90
 233 OpenDayLight Beryllium
 234
 235 Rationale for decisions
 236 -----------------------
 237 Pass
 238
 239 Conclusions and recommendations
 240 -------------------------------
 241 Tests were successfully executed and metrics collected.
 242 No SLA was verified. To be decided on in next release of OPNFV.
 243
 244
 245
 246 fuel
 247 ====
 248
 249 .. _Grafana: http://testresults.opnfv.org/grafana/dashboard/db/yardstick-main
 250 .. _POD2: https://wiki.opnfv.org/pharos?&#community_test_labs
 251
 252 Overview of test results
 253 ------------------------
 254
 255 See Grafana_ for viewing test result metrics for each respective test case. It
 256 is possible to chose which specific scenarios to look at, and then to zoom in
 257 on the details of each run test scenario as well.
 258
 259 All of the test case results below are based on 4 scenario test runs, each run
 260 on the Ericsson POD2_ or LF POD2_ between August 25 and 29 in 2016.
 261
 262 TC002
 263 -----
 264 The round-trip-time (RTT) between 2 VMs on different blades is measured using
 265 ping. Most test run measurements result on average between 0.5 and 0.6 ms.
 266 A few runs start with a 1 - 1.5 ms RTT spike (This could be because of normal ARP
 267 handling). One test run has a greater RTT spike of 1.9 ms, which is the same
 268 one with the 0.7 ms average. The other runs have no similar spike at all.
 269 To be able to draw conclusions more runs should be made.
 270 SLA set to 10 ms. The SLA value is used as a reference, it has not
 271 been defined by OPNFV.
 272
 273 TC005
 274 -----
 275 The IO read bandwidth looks similar between different dates, with an
 276 average between approx. 170 and 200 MB/s. Within each test run the results
 277 vary, with a minimum 2 MB/s and maximum 838 MB/s on the totality. Most runs
 278 have a minimum BW of 3 MB/s (two runs at 2 MB/s). The maximum BW varies more in
 279 absolute numbers between the dates, between 617 and 838 MB/s.
 280 SLA set to 400 MB/s. The SLA value is used as a reference, it has not been
 281 defined by OPNFV.
 282
 283 TC010
 284 -----
 285 The measurements for memory latency are similar between test dates and result
 286 in approx. 1.2 ns. The variations within each test run are similar, between
 287 1.215 and 1.219 ns. One exception is February 16, where the average is 1.222
 288 and varies between 1.22 and 1.28 ns.
 289 SLA set to 30 ns. The SLA value is used as a reference, it has not been defined
 290 by OPNFV.
 291
 292 TC011
 293 -----
 294 Packet delay variation between 2 VMs on different blades is measured using
 295 Iperf3. On the first date the reported packet delay variation varies between
 296 0.0025 and 0.011 ms, with an average delay variation of 0.0067 ms.
 297 On the second date the delay variation varies between 0.002 and 0.006 ms, with
 298 an average delay variation of 0.004 ms.
 299
 300 TC012
 301 -----
 302 Between test dates, the average measurements for memory bandwidth vary between
 303 17.4 and 17.9 GB/s. Within each test run the results vary more, with a minimal
 304 BW of 16.4 GB/s and maximum of 18.2 GB/s on the totality.
 305 SLA set to 15 GB/s. The SLA value is used as a reference, it has not been
 306 defined by OPNFV.
 307
 308 TC014
 309 -----
 310 The Unixbench processor test run results vary between scores 3080 and 3240,
 311 one result each date. The average score on the total is 3150.
 312 No SLA set.
 313
 314 TC037
 315 -----
 316 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 317 on different blades are measured when increasing the amount of UDP flows sent
 318 between the VMs using pktgen as packet generator tool.
 319
 320 Round trip times and packet throughput between VMs can typically be affected by
 321 the amount of flows set up and result in higher RTT and less PPS throughput.
 322
 323 The RTT results are similar throughout the different test dates and runs at
 324 approx. 15 ms. Some test runs show an increase with many flows, in the range
 325 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 326 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 327 RTT results.
 328 In some test runs when running with less than approx. 10000 flows the PPS
 329 throughput is normally flatter compared to when running with more flows, after
 330 which the PPS throughput decreases. Around 20 percent decrease in the worst
 331 case. For the other test runs there is however no significant change to the PPS
 332 throughput when the number of flows are increased. In some test runs the PPS
 333 is also greater with 1000000 flows compared to other test runs where the PPS
 334 result is less with only 2 flows.
 335
 336 The average PPS throughput in the different runs varies between 414000 and
 337 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 338 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 339 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 340 for RTT results).
 341
 342 There are lost packets reported in most of the test runs. There is no observed
 343 correlation between the amount of flows and the amount of lost packets.
 344 The lost amount of packets normally range between 100 and 1000 per test run,
 345 but there are spikes in the range of 10000 lost packets as well, and even
 346 more in a rare cases.
 347
 348 CPU utilization statistics are collected during UDP flows sent between the VMs
 349 using pktgen as packet generator tool. The average measurements for CPU
 350 utilization ratio vary between 1% to 2%. The peak of CPU utilization ratio
 351 appears around 7%.
 352
 353 TC069
 354 -----
 355 Between test dates, the average measurements for memory bandwidth vary between
 356 15.5 and 25.4 GB/s. Within each test run the results vary more, with a minimal
 357 BW of 9.7 GB/s and maximum of 29.5 GB/s on the totality.
 358 SLA set to 6 GB/s. The SLA value is used as a reference, it has not been
 359 defined by OPNFV.
 360
 361 TC070
 362 -----
 363 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 364 on different blades are measured when increasing the amount of UDP flows sent
 365 between the VMs using pktgen as packet generator tool.
 366
 367 Round trip times and packet throughput between VMs can typically be affected by
 368 the amount of flows set up and result in higher RTT and less PPS throughput.
 369
 370 The RTT results are similar throughout the different test dates and runs at
 371 approx. 15 ms. Some test runs show an increase with many flows, in the range
 372 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 373 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 374 RTT results.
 375 In some test runs when running with less than approx. 10000 flows the PPS
 376 throughput is normally flatter compared to when running with more flows, after
 377 which the PPS throughput decreases. Around 20 percent decrease in the worst
 378 case. For the other test runs there is however no significant change to the PPS
 379 throughput when the number of flows are increased. In some test runs the PPS
 380 is also greater with 1000000 flows compared to other test runs where the PPS
 381 result is less with only 2 flows.
 382
 383 The average PPS throughput in the different runs varies between 414000 and
 384 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 385 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 386 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 387 for RTT results).
 388
 389 There are lost packets reported in most of the test runs. There is no observed
 390 correlation between the amount of flows and the amount of lost packets.
 391 The lost amount of packets normally range between 100 and 1000 per test run,
 392 but there are spikes in the range of 10000 lost packets as well, and even
 393 more in a rare cases.
 394
 395 Memory utilization statistics are collected during UDP flows sent between the
 396 VMs using pktgen as packet generator tool. The average measurements for memory
 397 utilization vary between 225MB to 246MB. The peak of memory utilization appears
 398 around 340MB.
 399
 400 TC071
 401 -----
 402 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 403 on different blades are measured when increasing the amount of UDP flows sent
 404 between the VMs using pktgen as packet generator tool.
 405
 406 Round trip times and packet throughput between VMs can typically be affected by
 407 the amount of flows set up and result in higher RTT and less PPS throughput.
 408
 409 The RTT results are similar throughout the different test dates and runs at
 410 approx. 15 ms. Some test runs show an increase with many flows, in the range
 411 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 412 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 413 RTT results.
 414 In some test runs when running with less than approx. 10000 flows the PPS
 415 throughput is normally flatter compared to when running with more flows, after
 416 which the PPS throughput decreases. Around 20 percent decrease in the worst
 417 case. For the other test runs there is however no significant change to the PPS
 418 throughput when the number of flows are increased. In some test runs the PPS
 419 is also greater with 1000000 flows compared to other test runs where the PPS
 420 result is less with only 2 flows.
 421
 422 The average PPS throughput in the different runs varies between 414000 and
 423 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 424 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 425 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 426 for RTT results).
 427
 428 There are lost packets reported in most of the test runs. There is no observed
 429 correlation between the amount of flows and the amount of lost packets.
 430 The lost amount of packets normally range between 100 and 1000 per test run,
 431 but there are spikes in the range of 10000 lost packets as well, and even
 432 more in a rare cases.
 433
 434 Cache utilization statistics are collected during UDP flows sent between the
 435 VMs using pktgen as packet generator tool. The average measurements for cache
 436 utilization vary between 205MB to 212MB.
 437
 438 TC072
 439 -----
 440 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 441 on different blades are measured when increasing the amount of UDP flows sent
 442 between the VMs using pktgen as packet generator tool.
 443
 444 Round trip times and packet throughput between VMs can typically be affected by
 445 the amount of flows set up and result in higher RTT and less PPS throughput.
 446
 447 The RTT results are similar throughout the different test dates and runs at
 448 approx. 15 ms. Some test runs show an increase with many flows, in the range
 449 towards 16 to 17 ms. One exception standing out is Feb. 15 where the average
 450 RTT is stable at approx. 13 ms. The PPS results are not as consistent as the
 451 RTT results.
 452 In some test runs when running with less than approx. 10000 flows the PPS
 453 throughput is normally flatter compared to when running with more flows, after
 454 which the PPS throughput decreases. Around 20 percent decrease in the worst
 455 case. For the other test runs there is however no significant change to the PPS
 456 throughput when the number of flows are increased. In some test runs the PPS
 457 is also greater with 1000000 flows compared to other test runs where the PPS
 458 result is less with only 2 flows.
 459
 460 The average PPS throughput in the different runs varies between 414000 and
 461 452000 PPS. The total amount of packets in each test run is approx. 7500000 to
 462 8200000 packets. One test run Feb. 15 sticks out with a PPS average of
 463 558000 and approx. 1100000 packets in total (same as the on mentioned earlier
 464 for RTT results).
 465
 466 There are lost packets reported in most of the test runs. There is no observed
 467 correlation between the amount of flows and the amount of lost packets.
 468 The lost amount of packets normally range between 100 and 1000 per test run,
 469 but there are spikes in the range of 10000 lost packets as well, and even
 470 more in a rare cases.
 471
 472 Network utilization statistics are collected during UDP flows sent between the
 473 VMs using pktgen as packet generator tool. Total number of packets received per
 474 second was average on 200 kpps and total number of packets transmitted per
 475 second was average on 600 kpps.
 476
 477 Detailed test results
 478 ---------------------
 479 The scenario was run on Ericsson POD2_ and LF POD2_ with:
 480 Fuel 9.0
 481 OpenStack Mitaka
 482 OpenVirtualSwitch 2.5.90
 483 OpenDayLight Beryllium
 484
 485 Rationale for decisions
 486 -----------------------
 487 Pass
 488
 489 Tests were successfully executed and metrics collected.
 490 No SLA was verified. To be decided on in next release of OPNFV.
 491
 492 Conclusions and recommendations
 493 -------------------------------
 494 The pktgen test configuration has a relatively large base effect on RTT in
 495 TC037 compared to TC002, where there is no background load at all. Approx.
 496 15 ms compared to approx. 0.5 ms, which is more than a 3000 percentage
 497 difference in RTT results.
 498 Especially RTT and throughput come out with better results than for instance
 499 the *fuel-os-nosdn-nofeature-ha* scenario does. The reason for this should
 500 probably be further analyzed and understood. Also of interest could be
 501 to make further analyzes to find patterns and reasons for lost traffic.
 502 Also of interest could be to see if there are continuous variations where
 503 some test cases stand out with better or worse results than the general test
 504 case.
 505
 506
 507
 508 Joid
 509 =====
 510
 511 .. _Grafana: http://testresults.opnfv.org/grafana/dashboard/db/yardstick-main
 512 .. _POD6: https://wiki.opnfv.org/pharos?&#community_test_labs
 513
 514 Overview of test results
 515 ------------------------
 516
 517 See Grafana_ for viewing test result metrics for each respective test case. It
 518 is possible to chose which specific scenarios to look at, and then to zoom in
 519 on the details of each run test scenario as well.
 520
 521 All of the test case results below are based on 4 scenario test runs, each run
 522 on the Intel POD6_ between September 1 and 8 in 2016.
 523
 524 TC002
 525 -----
 526 The round-trip-time (RTT) between 2 VMs on different blades is measured using
 527 ping. Most test run measurements result on average between 1.01 ms and 1.88 ms.
 528 Only one test run has reached greatest RTT spike of 1.88 ms. Meanwhile, the
 529 smallest network latency is 1.01 ms, which is obtained on Sep. 1st. In general,
 530 the average of network latency of the four test runs are between 1.29 ms and
 531 1.34 ms. SLA set to be 10 ms. The SLA value is used as a reference, it has not
 532 been defined by OPNFV.
 533
 534 TC005
 535 -----
 536 The IO read bandwidth actually refers to the storage throughput, which is
 537 measured by fio and the greatest IO read bandwidth of the four runs is 183.65
 538 MB/s. The IO read bandwidth of the three runs looks similar, with an average
 539 between 62.9 and 64.3 MB/s, except one on Sep. 1, for its maximum storage
 540 throughput is only 159.1 MB/s. One of the runs has a minimum BW of 685 KB/s and
 541 other has a maximum BW of 183.6 MB/s. The SLA of read bandwidth sets to be
 542 400 MB/s, which is used as a reference, and it has not been defined by OPNFV.
 543
 544 The results of storage IOPS for the four runs look similar with each other. The
 545 IO read times per second of the four test runs have an average value between
 546 1.41k per second and 1.64k per second, and meanwhile, the minimum result is
 547 only 55 times per second.
 548
 549 TC010
 550 -----
 551 The tool we use to measure memory read latency is lmbench, which is a series of
 552 micro benchmarks intended to measure basic operating system and hardware system
 553 metrics. The memory read latency of the four runs is between 1.152 ns and 1.179
 554 ns on average. The variations within each test run are quite different, some
 555 vary from a large range and others have a small change. For example, the
 556 largest change is on September 8, the memory read latency of which is ranging
 557 from 1.120 ns to 1.221 ns. However, the results on September 7 change very
 558 little. The SLA sets to be 30 ns. The SLA value is used as a reference, it has
 559 not been defined by OPNFV.
 560
 561 TC011
 562 -----
 563 Iperf3 is a tool for evaluating the packet delay variation between 2 VMs on
 564 different blades. The reported packet delay variations of the four test runs
 565 differ from each other. In general, the packet delay of the first two runs look
 566 similar, for they both stay stable within each run. And the mean packet delay
 567 of them are 0.0087 ms and 0.0127 ms respectively. Of the four runs, the fourth
 568 has the worst result, because the packet delay reaches 0.0187 ms. The SLA value
 569 sets to be 10 ms. The SLA value is used as a reference, it has not been defined
 570 by OPNFV.
 571
 572 TC012
 573 -----
 574 Lmbench is also used to measure the memory read and write bandwidth, in which
 575 we use bw_mem to obtain the results. Among the four test runs, the trend of
 576 three memory bandwidth almost look similar, which all have a narrow range, and
 577 the average result is 11.78 GB/s. Here SLA set to be 15 GB/s. The SLA value is
 578 used as a reference, it has not been defined by OPNFV.
 579
 580 TC014
 581 -----
 582 The Unixbench is used to evaluate the IaaS processing speed with regards to
 583 score of single cpu running and parallel running. It can be seen from the
 584 dashboard that the processing test results vary from scores 3260k to 3328k, and
 585 there is only one result one date. No SLA set.
 586
 587 TC037
 588 -----
 589 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 590 on different blades are measured when increasing the amount of UDP flows sent
 591 between the VMs using pktgen as packet generator tool.
 592
 593 Round trip times and packet throughput between VMs can typically be affected by
 594 the amount of flows set up and result in higher RTT and less PPS throughput.
 595
 596 The mean packet throughput of the four test runs is between 307.3 kpps and
 597 447.1 kpps, of which the result of the third run is the highest. The RTT
 598 results of all the test runs keep flat at approx. 15 ms. It is obvious that the
 599 PPS results are not as consistent as the RTT results.
 600
 601 The No. flows of the four test runs are 240 k on average and the PPS results
 602 look a little waved since the largest packet throughput is 418.1 kpps and the
 603 minimum throughput is 326.5 kpps respectively.
 604
 605 There are no errors of packets received in the four runs, but there are still
 606 lost packets in all the test runs. The RTT values obtained by ping of the four
 607 runs have the similar average vaue, that is approx. 15 ms.
 608
 609 CPU load is measured by mpstat, and CPU load of the four test runs seem a
 610 little similar, since the minimum value and the peak of CPU load is between 0
 611 percent and nine percent respectively. And the best result is obtained on Sep.
 612 1, with an CPU load of nine percent. But on the whole, the CPU load is very
 613 poor, since the average value is quite small.
 614
 615 TC069
 616 -----
 617 With the block size changing from 1 kb to 512 kb, the memory write bandwidth
 618 tends to become larger first and then smaller within every run test, which
 619 rangs from 21.9 GB/s to 25.9 GB/s and then to 17.8 GB/s on average. Since the
 620 test id is one, it is that only the INT memory write bandwidth is tested. On
 621 the whole, when the block size is 2 kb or 16 kb, the memory write bandwidth
 622 look similar with a minimal BW of 24.8 GB/s and peak value of 27.8 GB/s. And
 623 then with the block size becoming larger, the memory write bandwidth tends to
 624 decrease. SLA sets to be 7 GB/s. The SLA value is used as a reference, it has
 625 not been defined by OPNFV.
 626
 627 TC070
 628 -----
 629 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 630 on different blades are measured when increasing the amount of UDP flows sent
 631 between the VMs using pktgen as packet generator tool.
 632
 633 Round trip times and packet throughput between VMs can typically be affected by
 634 the amount of flows set up and result in higher RTT and less PPS throughput.
 635
 636 The network latency is measured by ping, and the results of the four test runs
 637 look similar with each other, and within these test runs, the maximum RTT can
 638 reach 39 ms and the average RTT is usually approx. 15 ms. The network latency
 639 tested on Sep. 1 and Sep. 8 have a peak latency of 39 ms. But on the whole,
 640 the average RTTs of the five runs keep flat and the network latency is
 641 relatively short.
 642
 643 Memory utilization is measured by free, which can display amount of free and
 644 used memory in the system. The largest amount of used memory is 267 MiB for the
 645 four runs. In general, the four test runs have very large memory utilization,
 646 which can reach 257 MiB on average. On the other hand, for the mean free memory,
 647 the four test runs have the similar trend with that of the mean used memory.
 648 In general, the mean free memory change from 233 MiB to 241 MiB.
 649
 650 Packet throughput and packet loss can be measured by pktgen, which is a tool
 651 in the network for generating traffic loads for network experiments. The mean
 652 packet throughput of the four test runs seem quite different, ranging from
 653 305.3 kpps to 447.1 kpps. The average number of flows in these tests is
 654 240000, and each run has a minimum number of flows of 2 and a maximum number
 655 of flows of 1.001 Mil. At the same time, the corresponding average packet
 656 throughput is between 354.4 kpps and 381.8 kpps. In summary, the PPS results
 657 seem consistent. Within each test run of the four runs, when number of flows
 658 becomes larger, the packet throughput seems not larger at the same time.
 659
 660 TC071
 661 -----
 662 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 663 on different blades are measured when increasing the amount of UDP flows sent
 664 between the VMs using pktgen as packet generator tool.
 665
 666 Round trip times and packet throughput between VMs can typically be affected by
 667 the amount of flows set up and result in higher RTT and less PPS throughput.
 668
 669 The network latency is measured by ping, and the results of the four test runs
 670 look similar with each other. Within each test run, the maximum RTT is only 42
 671 ms and the average RTT is usually approx. 15 ms. On the whole, the average
 672 RTTs of the four runs keep stable and the network latency is relatively small.
 673
 674 Cache utilization is measured by cachestat, which can display size of cache and
 675 buffer in the system. Cache utilization statistics are collected during UDP
 676 flows sent between the VMs using pktgen as packet generator tool. The largest
 677 cache size is 212 MiB, which is same for the four runs, and the smallest cache
 678 size is 75 MiB. On the whole, the average cache size of the four runs look the
 679 same and is between 197 MiB and 211 MiB. Meanwhile, the tread of the buffer
 680 size keep flat, since they have a minimum value of 7 MiB and a maximum value of
 681 8 MiB, with an average value of about 7.9 MiB.
 682
 683 Packet throughput can be measured by pktgen, which is a tool in the network for
 684 generating traffic loads for network experiments. The mean packet throughput of
 685 the four test runs differ from 354.4 kpps to 381.8 kpps. The average number of
 686 flows in these tests is 240k, and each run has a minimum number of flows of 2
 687 and a maximum number of flows of 1.001 Mil. At the same time, the corresponding
 688 packet throughput differ between 305.3 kpps to 447.1 kpps. Within each test run
 689 of the four runs, when number of flows becomes larger, the packet throughput
 690 seems not larger in the meantime.
 691
 692 TC072
 693 -----
 694 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 695 on different blades are measured when increasing the amount of UDP flows sent
 696 between the VMs using pktgen as packet generator tool.
 697
 698 Round trip times and packet throughput between VMs can typically be affected by
 699 the amount of flows set up and result in higher RTT and less PPS throughput.
 700
 701 The RTT results are similar throughout the different test dates and runs
 702 between 0 ms and 42 ms with an average leatency of less than 15 ms. The PPS
 703 results are not as consistent as the RTT results, for the mean packet
 704 throughput of the four runs differ from 354.4 kpps to 381.8 kpps.
 705
 706 Network utilization is measured by sar, that is system activity reporter, which
 707 can display the average statistics for the time since the system was started.
 708 Network utilization statistics are collected during UDP flows sent between the
 709 VMs using pktgen as packet generator tool. The largest total number of packets
 710 transmitted per second look similar for three test runs, whose values change a
 711 lot from 10 pps to 501 kpps. While results of the rest test run seem the same
 712 and keep stable with the average number of packets transmitted per second of 10
 713 pps. However, the total number of packets received per second of the four runs
 714 look similar, which have a large wide range of 2 pps to 815 kpps.
 715
 716 In some test runs when running with less than approx. 251000 flows the PPS
 717 throughput is normally flatter compared to when running with more flows, after
 718 which the PPS throughput decreases. For the other test runs there is however no
 719 significant change to the PPS throughput when the number of flows are
 720 increased. In some test runs the PPS is also greater with 251000 flows
 721 compared to other test runs where the PPS result is less with only 2 flows.
 722
 723 There are lost packets reported in most of the test runs. There is no observed
 724 correlation between the amount of flows and the amount of lost packets.
 725 The lost amount of packets normally differs a lot per test run.
 726
 727 Detailed test results
 728 ---------------------
 729 The scenario was run on Intel POD6_ with:
 730 Joid
 731 OpenStack Mitaka
 732 OpenVirtualSwitch 2.5.90
 733 OpenDayLight Beryllium
 734
 735 Rationale for decisions
 736 -----------------------
 737 Pass
 738
 739 Conclusions and recommendations
 740 -------------------------------
 741 Tests were successfully executed and metrics collected.
 742 No SLA was verified. To be decided on in next release of OPNFV.
 743