docs/new/cpta/methodology/index.rst

   1 .. _trending_methodology:
   2
   3 Trending Methodology
   4 ====================
   5
   6 Overview
   7 --------
   8
   9 This document describes a high-level design of a system for continuous
  10 performance measuring, trending and change detection for FD.io VPP SW
  11 data plane. It builds upon the existing FD.io CSIT framework with
  12 extensions to its throughput testing methodology, CSIT data analytics
  13 engine (PAL – Presentation-and-Analytics-Layer) and associated Jenkins
  14 jobs definitions.
  15
  16 Proposed design replaces existing CSIT performance trending jobs and
  17 tests with new Performance Trending (PT) CSIT module and separate
  18 Performance Analysis (PA) module ingesting results from PT and
  19 analysing, detecting and reporting any performance anomalies using
  20 historical trending data and statistical metrics. PA does also produce
  21 trending dashboard and graphs with summary and drill-down views across
  22 all specified tests that can be reviewed and inspected regularly by
  23 FD.io developers and users community.
  24
  25 Performance Tests
  26 -----------------
  27
  28 Performance trending is currently relying on the Maximum Receive Rate
  29 (MRR) tests. MRR tests measure the packet forwarding rate under the
  30 maximum load offered by traffic generator over a set trial duration,
  31 regardless of packet loss. Maximum load for specified Ethernet frame
  32 size is set to the bi-directional link rate.
  33
  34 Current parameters for performance trending MRR tests:
  35
  36 - **Ethernet frame sizes**: 64B (78B for IPv6 tests) for all tests, IMIX for
  37   selected tests (vhost, memif); all quoted sizes include frame CRC, but
  38   exclude per frame transmission overhead of 20B (preamble, inter frame
  39   gap).
  40 - **Maximum load offered**: 10GE and 40GE link (sub-)rates depending on NIC
  41   tested, with the actual packet rate depending on frame size,
  42   transmission overhead and traffic generator NIC forwarding capacity.
  43
  44   - For 10GE NICs the maximum packet rate load is 2* 14.88 Mpps for 64B,
  45     a 10GE bi-directional link rate.
  46   - For 40GE NICs the maximum packet rate load is 2* 18.75 Mpps for 64B,
  47     a 40GE bi-directional link sub-rate limited by TG 40GE NIC used,
  48     XL710.
  49
  50 - **Trial duration**: 10sec.
  51 - **Execution frequency**: twice a day, every 12 hrs (02:00, 14:00 UTC).
  52
  53 Note: MRR tests should be reporting bi-directional link rate (or NIC
  54 rate, if lower) if tested VPP configuration can handle the packet rate
  55 higher than bi-directional link rate, e.g. large packet tests and/or
  56 multi-core tests. In other words MRR = min(VPP rate, bi-dir link rate,
  57 NIC rate).
  58
  59 Trend Analysis
  60 --------------
  61
  62 All measured performance trend data is treated as time-series data that
  63 can be modelled as concatenation of groups, each group modelled
  64 using normal distribution. While sometimes the samples within a group
  65 are far from being distributed normally, we do not have a better tractable model.
  66
  67 The group boundaries are selected based on `Minimum Description Length`_.
  68
  69 TODO: Decide the level of detail for describing group selection.
  70
  71 Anomaly Detection
  72 `````````````````
  73
  74 Once the trend data is divided into groups, each group has its population average.
  75 The start of the following group is marked as a regression (or progression)
  76 if the new group's average is lower (higher) then the previous group's.
  77
  78 Metrics
  79 ```````
  80
  81 TODO: Only needed for current trend compliance.
  82
  83 Following statistical metrics are used as performance trend indicators
  84 over the rolling window of last <N> sets of historical measurement data:
  85
  86 - **TMM** : **Trimmed Moving Median**, median across the data set of <N>
  87   values excluding the outliers. Used as a trending value and as a
  88   reference for anomaly detection.
  89
  90 Trend Compliance
  91 ````````````````
  92
  93 TODO: Apply new detection algorithm also to trend compliance.
  94
  95 Trend compliance metrics are targeted to provide an indication of trend
  96 changes over a short-term (i.e. weekly) and a long-term (i.e.
  97 quarterly), comparing the last trend value, TMM[last], to one from week
  98 ago, TMM[last - 1week] and to the maximum of trend values over last
  99 quarter except last week, max(TMM[(last - 3mths)..(last - 1week)]),
 100 respectively. This results in following trend compliance calculations:
 101
 102 +-------------------------+---------------------------------+-----------+------------------------------------------+
 103 | Trend Compliance Metric | Trend Change Formula            | Value     | Reference                                |
 104 +=========================+=================================+===========+==========================================+
 105 | Short-Term Change       | (Value - Reference) / Reference | TMM[last] | TMM[last - 1week]                        |
 106 +-------------------------+---------------------------------+-----------+------------------------------------------+
 107 | Long-Term Change        | (Value - Reference) / Reference | TMM[last] | max(TMM[(last - 3mths)..(last - 1week)]) |
 108 +-------------------------+---------------------------------+-----------+------------------------------------------+
 109
 110 Trend Presentation
 111 ------------------
 112
 113 Performance Dashboard
 114 `````````````````````
 115
 116 Dashboard tables list a summary of per test-case VPP MRR performance
 117 trend and trend compliance metrics and detected number of anomalies.
 118
 119 Separate tables are generated for tested VPP worker-thread-core
 120 combinations (1t1c, 2t2c, 4t4c). Test case names are linked to
 121 respective trending graphs for ease of navigation thru the test data.
 122
 123 Trendline Graphs
 124 ````````````````
 125
 126 Trendline graphs show per test case measured MRR throughput values with
 127 associated gruop averages. The graphs are constructed as follows:
 128
 129 - X-axis represents performance trend job build Id (csit-vpp-perf-mrr-
 130   daily-master-build).
 131 - Y-axis represents MRR throughput in Mpps.
 132 - Markers to indicate anomaly classification:
 133
 134   - Outlier - gray circle around MRR value point.
 135   - Regression - red circle.
 136   - Progression - green circle.
 137
 138 In addition the graphs show dynamic labels while hovering over graph
 139 data points, representing (trend job build Id, MRR value) and the actual
 140 vpp build number (b<XXX>) tested.
 141
 142
 143 Jenkins Jobs
 144 ------------
 145
 146 Performance Trending (PT)
 147 `````````````````````````
 148
 149 CSIT PT runs regular performance test jobs measuring and collecting MRR
 150 data per test case. PT is designed as follows:
 151
 152 1. PT job triggers:
 153
 154    a) Periodic e.g. daily.
 155    b) On-demand gerrit triggered.
 156
 157 2. Measurements and data calculations per test case:
 158
 159   a) Max Received Rate (MRR) - send packets at link rate over a trial
 160      period, count total received packets, divide by trial period.
 161
 162 3. Archive MRR per test case.
 163 4. Archive all counters collected at MRR.
 164
 165 Performance Analysis (PA)
 166 `````````````````````````
 167
 168 CSIT PA runs performance analysis including trendline calculation, trend
 169 compliance and anomaly detection using specified trend analysis metrics
 170 over the rolling window of last <N> sets of historical measurement data.
 171 PA is defined as follows:
 172
 173 1. PA job triggers:
 174
 175    a) By PT job at its completion.
 176    b) On-demand gerrit triggered.
 177
 178 2. Download and parse archived historical data and the new data:
 179
 180    a) Download RF output.xml files from latest PT job and compressed
 181       archived data.
 182    b) Parse out the data filtering test cases listed in PA specification
 183       (part of CSIT PAL specification file).
 184
 185 3. Re-calculate new groups and their averages.
 186
 187 4. Evaluate new test data (TODO: Update.):
 188
 189    a) If within the range of (TMA +/- 3*TMSD) => Result = Pass,
 190       Reason = Normal. (to be updated base on the final Jenkins code).
 191    b) If below the range => Result = Fail, Reason = Regression.
 192    c) If above the range => Result = Pass, Reason = Progression.
 193
 194 5. Generate and publish results
 195
 196    a) Relay evaluation result to job result. (to be updated base on the
 197       final Jenkins code).
 198    b) Generate a new set of trend summary dashboard and graphs.
 199    c) Publish trend dashboard and graphs in html format on
 200       https://docs.fd.io/.
 201
 202 Testbed HW configuration
 203 ------------------------
 204
 205 The testbed HW configuration is described on
 206 `this FD.IO wiki page <https://wiki.fd.io/view/CSIT/CSIT_LF_testbed#FD.IO_CSIT_testbed_-_Server_HW_Configuration>`_.
 207
 208 .. _Minimum Description Length: https://en.wikipedia.org/wiki/Minimum_description_length