results/fuel-os-onos-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-onos-nofeature-ha
   8 ==========================================
   9
  10 .. toctree::
  11    :maxdepth: 2
  12
  13
  14 Details
  15 =======
  16
  17 .. _Grafana: http://130.211.154.108/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 7 scenario test
  28 runs, each run on the Ericsson POD2_ between February 13 and 21 in 2016. Test
  29 case TC011_ is not reported on due to an InfluxDB issue.
  30 The best would be to have more runs to draw better conclusions from, but these
  31 are the only runs available at the time of OPNFV R2 release.
  32
  33 TC002
  34 -----
  35 The round-trip-time (RTT) between 2 VMs on different blades is measured using
  36 ping. The majority (5) of the test run measurements result in an average
  37 between 0.4 and 0.5 ms. The other 2 dates stick out with an RTT average of 0.9
  38 to 1 ms.
  39 The majority of the runs start with a 1 - 1.5 ms RTT spike (This could be
  40 because of normal ARP handling). One test run has a greater RTT spike of 4 ms,
  41 which is the same one with the 1 ms RTT average. The other runs have no similar
  42 spike at all. To be able to draw conclusions more runs should be made.
  43 SLA set to 10 ms. The SLA value is used as a reference, it has not
  44 been defined by OPNFV.
  45
  46 TC005
  47 -----
  48 The IO read bandwidth looks similar between different dates, with an
  49 average between approx. 170 and 185 MB/s. Within each test run the results
  50 vary, with a minimum of 2 MB/s and maximum of 690MB/s on the totality. Most
  51 runs have a minimum BW of 3 MB/s (one run at 2 MB/s). The maximum BW varies
  52 more in absolute numbers between the dates, between 560 and 690 MB/s.
  53 SLA set to 400 MB/s. The SLA value is used as a reference, it has not been
  54 defined by OPNFV.
  55
  56 TC010
  57 -----
  58 The measurements for memory latency are similar between test dates and result
  59 in a little less average than 1.22 ns. The variations within each test run are
  60 similar, between 1.213 and 1.226 ns. One exception is the first date, where the
  61 average is 1.223 and varies between 1.215 and 1.275 ns.
  62 SLA set to 30 ns. The SLA value is used as a reference, it has not been defined
  63 by OPNFV.
  64
  65 TC011
  66 -----
  67 For this scenario no results are available to report on. Reason is an
  68 integer/floating point issue regarding how InfluxDB is populated with
  69 result data from the test runs. The issue was fixed but not in time to produce
  70 input for this report.
  71
  72 TC012
  73 -----
  74 Between test dates the average measurements for memory bandwidth vary between
  75 17.1 and 18.1 GB/s. Within each test run the results vary more, with a minimal
  76 BW of 15.5 GB/s and maximum of 18.2 GB/s on the totality.
  77 SLA set to 15 GB/s. The SLA value is used as a reference, it has not been
  78 defined by OPNFV.
  79
  80 TC014
  81 -----
  82 The Unixbench processor test run results vary between scores 3100 and 3260,
  83 one result each date. The average score on the total is 3170.
  84 No SLA set.
  85
  86 TC037
  87 -----
  88 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
  89 on different blades are measured when increasing the amount of UDP flows sent
  90 between the VMs using pktgen as packet generator tool.
  91
  92 Round trip times and packet throughput between VMs can typically be affected by
  93 the amount of flows set up and result in higher RTT and less PPS throughput.
  94
  95 There seems to be mainly two result types. One type a high and flatter
  96 PPS throughput not very much affected by the number of flows. Here also the
  97 average RTT is stable around 13 ms throughout all the test runs.
  98
  99 The second type starts with a slightly lower PPS in the beginning than type
 100 one, and decreases even further when passing approx. 10000 flows. Here also the
 101 average RTT tends to start at approx. 15 ms ending with an average of 17 to 18
 102 ms with the maximum amount of flows running.
 103
 104 Result type one can with the maximum amount of flows have a greater PPS than
 105 the second type with the minimum amount of flows.
 106
 107 For result type one the average PPS throughput in the different runs varies
 108 between 399000 and 447000 PPS. The total amount of packets in each test run
 109 is between approx. 7000000 and 10200000 packets.
 110 The second result type has a PPS average of between 602000 and 621000 PPS and a
 111 total packet amount between 10900000 and 13500000 packets.
 112
 113 There are lost packets reported in many of the test runs. There is no observed
 114 correlation between the amount of flows and the amount of lost packets.
 115 The lost amount of packets normally range between 100 and 1000 per test run,
 116 but there are spikes in the range of 10000 lost packets as well, and even
 117 more in a rare cases. Some case is in the range of one million lost packets.
 118
 119 Detailed test results
 120 ---------------------
 121 The scenario was run on Ericsson POD2_ with:
 122 Fuel 8.0
 123 OpenStack Liberty
 124 OpenVirtualSwitch 2.3.1
 125 OpenNetworkOperatingSystem Drake
 126
 127 Rationale for decisions
 128 -----------------------
 129 Pass
 130
 131 Tests were successfully executed and metrics collected.
 132 No SLA was verified. To be decided on in next release of OPNFV.
 133
 134 Conclusions and recommendations
 135 -------------------------------
 136 The pktgen test configuration has a relatively large base effect on RTT in
 137 TC037 compared to TC002, where there is no background load at all. Approx.
 138 15 ms compared to approx. 0.5 ms, which is more than a 3000 percentage
 139 difference in RTT results.
 140 Especially RTT and throughput come out with better results than for instance
 141 the *fuel-os-nosdn-nofeature-ha* scenario does. The reason for this should
 142 probably be further analyzed and understood. Also of interest could be
 143 to make further analyzes to find patterns and reasons for lost traffic.
 144 Also of interest could be to see why there are variations in some test cases,
 145 especially visible in TC037.
 146