docs/results/compass-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 compass-os-nosdn-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 .. _SC_POD: 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 5 consecutive scenario test
  28 runs, each run on the Huawei SC_POD_ between February 13 and 18 in 2016. The
  29 best would be to have more runs to draw better conclusions from, but these are
  30 the only runs available at the time of OPNFV R2 release
  31
  32 TC002
  33 -----
  34 The round-trip-time (RTT) between 2 VMs on different blades is measured using
  35 ping. The measurements are on average varying between 1.95 and 2.23 ms
  36 with a first 2 - 3.27 ms RTT spike in the beginning of each run (This could be
  37 because of normal ARP handling).SLA set to 10 ms. The SLA value is used as a
  38 reference, it has not been defined by OPNFV.
  39
  40 TC005
  41 -----
  42 The IO read bandwidth look similar between different test runs, with an
  43 average at approx. 145-162 MB/s. Within each run the results vary much,
  44 minimum 2MB/s and maximum 712MB/s on the totality.
  45 SLA set to 400KB/s. The SLA value is used as a reference, it has not been
  46 defined by OPNFV.
  47
  48 TC010
  49 -----
  50 The measurements for memory latency are consistent among test runs and results
  51 in approx. 1.2 ns. The variations between runs are similar, between
  52 1.215 and 1.278 ns.  SLA set to 30 ns. The SLA value is used as
  53 a reference, it has not been defined by OPNFV.
  54
  55 TC011
  56 -----
  57 For this scenario no results are available to report on. Probable reason is
  58 an integer/floating point issue regarding how InfluxDB is populated with
  59 result data from the test runs.
  60
  61 TC012
  62 -----
  63 The average measurements for memory bandwidth are consistent among most of the
  64 different test runs at 12.98 - 16.73 GB/s. The last test run averages at
  65 16.67 GB/s. Within each run the results vary, with minimal BW of 16.59
  66 GB/s and maximum of 16.71 GB/s of the totality.
  67 SLA set to 15 GB/s. The SLA value is used as a reference, it has not been
  68 defined by OPNFV.
  69
  70 TC014
  71 -----
  72 The Unixbench processor single and parallel speed scores show similar results
  73 at approx. 3000. The runs vary between scores 2499 and 3105.
  74 No SLA set.
  75
  76 TC027
  77 -----
  78 The round-trip-time (RTT) between VM1 with ipv6 router on different blades is
  79 measured using ping6. The measurements are consistent at approx. 4 ms.
  80 SLA set to 30 ms.The SLA value is used as a reference, it has not been
  81 defined by OPNFV.
  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 are typically affected by
  90 the amount of flows set up and result in higher RTT and less PPS
  91 throughput.
  92
  93 When running with less than 10000 flows the results are flat and consistent.
  94 RTT is then approx. 30 ms and the number of PPS remains flat at approx.
  95 230000 PPS. Beyond approx. 10000 flows and up to 1000000 (one million) there
  96 is an even drop in RTT and PPS performance, eventually ending up at approx.
  97 105-113 ms and 100000 PPS respectively.
  98
  99 TC040
 100 -----
 101 test purpose is to verify the function of Yang-to-Tosca in Parse, and this test
 102 case is a weekly task, so it was triggered by manually, the result whether the
 103 output is same with expected outcome is success
 104 No SLA set.
 105
 106 Detailed test results
 107 ---------------------
 108
 109 The scenario was run on Huawei SC_POD_ with:
 110 Compass 1.0
 111 OpenStack Liberty
 112 OVS 2.4.0
 113
 114 No SDN controller installed
 115
 116 Rationale for decisions
 117 -----------------------
 118 Pass
 119
 120 Tests were successfully executed and metrics collects (apart from TC011_).
 121 No SLA was verified. To be decided on in next release of OPNFV.
 122
 123 Conclusions and recommendations
 124 -------------------------------
 125
 126 The pktgen test configuration has a relatively large base effect on RTT in
 127 TC037 compared to TC002, where there is no background load at all (30 ms
 128 compared to 1 ms or less, which is more than a 3000 percentage different
 129 in RTT results). The larger amounts of flows in TC037 generate worse
 130 RTT results, in the magnitude of several hundreds of milliseconds. It would
 131 be interesting to also make and compare all these measurements to completely
 132 (optimized) bare metal machines running native Linux with all other relevant
 133 tools available, e.g. lmbench, pktgen etc.