docs/results/os-odl_l2-sfc-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-sfc-ha
   8 ==================================
   9
  10 .. toctree::
  11    :maxdepth: 2
  12
  13
  14 Fuel
  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 runs, each run
  28 on the LF POD2_ or Ericsson POD2_ between September 16 and 20 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.32 ms and 1.42 ms.
  34 Only one test run on Sep. 20 has reached greatest RTT spike of 4.66 ms.
  35 Meanwhile, the smallest network latency is 0.16 ms, which is obtained on Sep.
  36 17th. To sum up, the curve of network latency has very small wave, which is
  37 less than 5 ms. SLA sets to be 10 ms. The SLA value is used as a reference, it
  38 has not been defined by OPNFV.
  39
  40 TC005
  41 -----
  42 The IO read bandwidth actually refers to the storage throughput, which is
  43 measured by fio and the greatest IO read bandwidth of the four runs is 734
  44 MB/s. The IO read bandwidth of the first three runs looks similar, with an
  45 average of less than 100 KB/s, except one on Sep. 20, whose maximum storage
  46 throughput can reach 734 MB/s. The SLA of read bandwidth sets to be 400 MB/s,
  47 which is used as a reference, and it has not been defined by OPNFV.
  48
  49 The results of storage IOPS for the four runs look similar with each other. The
  50 IO read times per second of the four test runs have an average value between
  51 1.8k per second and 3.27k per second, and meanwhile, the minimum result is
  52 only 60 times per second.
  53
  54 TC010
  55 -----
  56 The tool we use to measure memory read latency is lmbench, which is a series of
  57 micro benchmarks intended to measure basic operating system and hardware system
  58 metrics. The memory read latency of the four runs is between 1.085 ns and 1.218
  59 ns on average. The variations within each test run are quite small. For
  60 Ericsson pod2, the average of memory latency is approx. 1.217 ms. While for LF
  61 pod2, the average value is about 1.085 ms. It can be seen that the performance
  62 of LF is better than Ericsson's. The SLA sets to be 30 ns. The SLA value is
  63 used as a reference, it has not been defined by OPNFV.
  64
  65 TC012
  66 -----
  67 Lmbench is also used to measure the memory read and write bandwidth, in which
  68 we use bw_mem to obtain the results. The four test runs all have a narrow range
  69 of change with the average memory and write BW of 18.5 GB/s. Here SLA set to be
  70 15 GB/s. The SLA value is used as a reference, it has not been defined by OPNFV.
  71
  72 TC014
  73 -----
  74 The Unixbench is used to evaluate the IaaS processing speed with regards to
  75 score of single cpu running and parallel running. It can be seen from the
  76 dashboard that the processing test results vary from scores 3209k to 3843k, and
  77 there is only one result one date. 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 mean packet throughput of the three test runs is between 439 kpps and
  89 582 kpps, and the test run on Sep. 17th has the lowest average value of 371
  90 kpps. The RTT results of all the test runs keep flat at approx. 10 ms. It is
  91 obvious that the PPS results are not as consistent as the RTT results.
  92
  93 The No. flows of the four test runs are 240 k on average and the PPS results
  94 look a little waved, since the largest packet throughput is 680 kpps and the
  95 minimum throughput is 319 kpps respectively.
  96
  97 There are no errors of packets received in the four runs, but there are still
  98 lost packets in all the test runs. The RTT values obtained by ping of the four
  99 runs have the similar trend of RTT with the average value of approx. 12 ms.
 100
 101 CPU load is measured by mpstat, and CPU load of the four test runs seem a
 102 little similar, since the minimum value and the peak of CPU load is between 0
 103 percent and ten percent respectively. And the best result is obtained on Sep.
 104 17th, with an CPU load of ten percent. But on the whole, the CPU load is very
 105 poor, since the average value is quite small.
 106
 107 TC069
 108 -----
 109 With the block size changing from 1 kb to 512 kb, the average memory write
 110 bandwidth tends to become larger first and then smaller within every run test
 111 for the two pods, which rangs from 25.1 GB/s to 29.4 GB/s and then to 19.2 GB/s
 112 on average. Since the test id is one, it is that only the INT memory write
 113 bandwidth is tested. On the whole, with the block size becoming larger, the
 114 memory write bandwidth tends to decrease. SLA sets to be 7 GB/s. The SLA value
 115 is used as a reference, it has not been defined by OPNFV.
 116
 117 TC070
 118 -----
 119 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 120 on different blades are measured when increasing the amount of UDP flows sent
 121 between the VMs using pktgen as packet generator tool.
 122
 123 Round trip times and packet throughput between VMs can typically be affected by
 124 the amount of flows set up and result in higher RTT and less PPS throughput.
 125
 126 The network latency is measured by ping, and the results of the four test runs
 127 look similar with each other, and within these test runs, the maximum RTT can
 128 reach 27 ms and the average RTT is usually approx. 12 ms. The network latency
 129 tested on Sep. 27th has a peak latency of 27 ms. But on the whole, the average
 130 RTTs of the four runs keep flat.
 131
 132 Memory utilization is measured by free, which can display amount of free and
 133 used memory in the system. The largest amount of used memory is 269 MiB for the
 134 four runs. In general, the four test runs have very large memory utilization,
 135 which can reach 251 MiB on average. On the other hand, for the mean free memory,
 136 the four test runs have the similar trend with that of the mean used memory.
 137 In general, the mean free memory change from 231 MiB to 248 MiB.
 138
 139 Packet throughput and packet loss can be measured by pktgen, which is a tool
 140 in the network for generating traffic loads for network experiments. The mean
 141 packet throughput of the four test runs seem quite different, ranging from
 142 371 kpps to 582 kpps. The average number of flows in these tests is
 143 240000, and each run has a minimum number of flows of 2 and a maximum number
 144 of flows of 1.001 Mil. At the same time, the corresponding average packet
 145 throughput is between 319 kpps and 680 kpps. In summary, the PPS results
 146 seem consistent. Within each test run of the four runs, when number of flows
 147 becomes larger, the packet throughput seems not larger at the same time.
 148
 149 TC071
 150 -----
 151 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 152 on different blades are measured when increasing the amount of UDP flows sent
 153 between the VMs using pktgen as packet generator tool.
 154
 155 Round trip times and packet throughput between VMs can typically be affected by
 156 the amount of flows set up and result in higher RTT and less PPS throughput.
 157
 158 The network latency is measured by ping, and the results of the four test runs
 159 look similar with each other. Within each test run, the maximum RTT is only 24
 160 ms and the average RTT is usually approx. 12 ms. On the whole, the average
 161 RTTs of the four runs keep stable and the network latency is relatively small.
 162
 163 Cache utilization is measured by cachestat, which can display size of cache and
 164 buffer in the system. Cache utilization statistics are collected during UDP
 165 flows sent between the VMs using pktgen as packet generator tool. The largest
 166 cache size is 213 MiB, and the smallest cache size is 99 MiB, which is same for
 167 the four runs. On the whole, the average cache size of the four runs look the
 168 same and is between 184 MiB and 205 MiB. Meanwhile, the tread of the buffer
 169 size keep stable, since they have a minimum value of 7 MiB and a maximum value of
 170 8 MiB.
 171
 172 Packet throughput can be measured by pktgen, which is a tool in the network for
 173 generating traffic loads for network experiments. The mean packet throughput of
 174 the four test runs differ from 371 kpps to 582 kpps. The average number of
 175 flows in these tests is 240k, and each run has a minimum number of flows of 2
 176 and a maximum number of flows of 1.001 Mil. At the same time, the corresponding
 177 packet throughput differ between 319 kpps to 680 kpps. Within each test run
 178 of the four runs, when number of flows becomes larger, the packet throughput
 179 seems not larger in the meantime.
 180
 181 TC072
 182 -----
 183 The amount of packets per second (PPS) and round trip times (RTT) between 2 VMs
 184 on different blades are measured when increasing the amount of UDP flows sent
 185 between the VMs using pktgen as packet generator tool.
 186
 187 Round trip times and packet throughput between VMs can typically be affected by
 188 the amount of flows set up and result in higher RTT and less PPS throughput.
 189
 190 The RTT results are similar throughout the different test dates and runs
 191 between 0 ms and 24 ms with an average leatency of less than 13 ms. The PPS
 192 results are not as consistent as the RTT results, for the mean packet
 193 throughput of the four runs differ from 370 kpps to 582 kpps.
 194
 195 Network utilization is measured by sar, that is system activity reporter, which
 196 can display the average statistics for the time since the system was started.
 197 Network utilization statistics are collected during UDP flows sent between the
 198 VMs using pktgen as packet generator tool. The largest total number of packets
 199 transmitted per second look similar for the four test runs, whose values change a
 200 lot from 10 pps to 697 kpps. However, the total number of packets received per
 201 second of three runs look similar, which have a large wide range of 2 pps to
 202 1.497 Mpps, while the results on Sep. 18th and 20th have very small maximum
 203 number of packets received per second of 817 kpps.
 204
 205 In some test runs when running with less than approx. 251000 flows the PPS
 206 throughput is normally flatter compared to when running with more flows, after
 207 which the PPS throughput decreases. For the other test runs there is however no
 208 significant change to the PPS throughput when the number of flows are
 209 increased. In some test runs the PPS is also greater with 251000 flows
 210 compared to other test runs where the PPS result is less with only 2 flows.
 211
 212 There are lost packets reported in most of the test runs. There is no observed
 213 correlation between the amount of flows and the amount of lost packets.
 214 The lost amount of packets normally differs a lot per test run.
 215
 216 Detailed test results
 217 ---------------------
 218 The scenario was run on Ericsson POD2_ and LF POD2_ with:
 219 Fuel 9.0
 220 OpenStack Mitaka
 221 OpenVirtualSwitch 2.5.90
 222 OpenDayLight Beryllium
 223
 224 Rationale for decisions
 225 -----------------------
 226 Pass
 227
 228 Conclusions and recommendations
 229 -------------------------------
 230 Tests were successfully executed and metrics collected.
 231 No SLA was verified. To be decided on in next release of OPNFV.