1 .. _trending_methodology:
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
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.
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.
34 Current parameters for performance trending MRR tests:
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
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.
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,
50 - **Trial duration**: 10sec.
51 - **Execution frequency**: twice a day, every 12 hrs (02:00, 14:00 UTC).
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,
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.
67 The group boundaries are selected based on `Minimum Description Length`_.
69 TODO: Decide the level of detail for describing group selection.
71 Minimum Description Length
72 --------------------------
74 `Minimum Description Length`_ (MDL) is a particular formalization
75 of `Occam's razor`_ principle.
77 The general formulation mandates to evaluate a large set of models,
78 but for anomaly detection purposes, it is usefuls to consider
79 a smaller set of models, so that scoring and comparing them is easier.
81 For each candidate model, the data should be losslessly compressed,
82 which includes model definitions, encoded model parameters,
83 and the raw data encoded based on probabilities computed by the model.
84 The model resulting in shortest compressed message is the "the" correct model.
86 For our model set (groups of normally distributed samples),
87 we need to encode group length (which penalizes too many groups),
88 group average (more on that later), group stdev and then all the samples.
90 Luckily, the "all the samples" part turns out to be quite easy to compute.
91 If sample values are considered as coordinates in (multi-dimensional)
92 Euclidean space, fixing stdev means the point with allowed coordinates
93 lays on a sphere. Fixing average intersects the sphere with a (hyper)-plane,
94 and Gaussian probability density on the resulting sphere is constant.
95 So the only contribution is the "area" of the sphere, which only depends
96 on the number of samples and stdev.
98 A somehow ambiguous part is in choosing which encoding
99 is used for group size, average and stdev.
100 Diferent encodings cause different biases to large or small values.
101 In our implementation we have chosen probability density
102 corresponding to uniform distribution (from zero to maximal sample value)
103 for stdev and average of the first group,
104 but for averages of subsequent groups we have chosen a distribution
105 which disourages deliminating groups with averages close together.
107 One part of our implementation which is not precise enough
108 is handling of measurement precision.
109 The minimal difference in MRR values is currently 0.1 pps
110 (the difference of one packet over 10 second trial),
111 but the code assumes the precision is 1.0.
112 Also, all the calculations assume 1.0 is totally negligible,
113 compared to stdev value.
115 The resulting group distribution looks good
116 if samples are distributed normally enough within a group.
117 But for obviously different distributions (for example `bimodal distribution`_)
118 the groups tend to focus on less relevant factors (such as "outlier" density).
123 Once the trend data is divided into groups, each group has its population average.
124 The start of the following group is marked as a regression (or progression)
125 if the new group's average is lower (higher) then the previous group's.
130 Trend compliance metrics are targeted to provide an indication of trend
131 changes over a short-term (i.e. weekly) and a long-term (i.e.
132 quarterly), comparing the last group average AVG[last], to the one from week
133 ago, AVG[last - 1week] and to the maximum of trend values over last
134 quarter except last week, max(AVG[last - 3mths]..ANV[last - 1week]),
135 respectively. This results in following trend compliance calculations:
137 +-------------------------+---------------------------------+-----------+-------------------------------------------+
138 | Trend Compliance Metric | Trend Change Formula | Value | Reference |
139 +=========================+=================================+===========+===========================================+
140 | Short-Term Change | (Value - Reference) / Reference | AVG[last] | AVG[last - 1week] |
141 +-------------------------+---------------------------------+-----------+-------------------------------------------+
142 | Long-Term Change | (Value - Reference) / Reference | AVG[last] | max(AVG[last - 3mths]..AVG[last - 1week]) |
143 +-------------------------+---------------------------------+-----------+-------------------------------------------+
148 Performance Dashboard
149 `````````````````````
151 Dashboard tables list a summary of per test-case VPP MRR performance
152 trend and trend compliance metrics and detected number of anomalies.
154 Separate tables are generated for tested VPP worker-thread-core
155 combinations (1t1c, 2t2c, 4t4c). Test case names are linked to
156 respective trending graphs for ease of navigation thru the test data.
161 Trendline graphs show per test case measured MRR throughput values with
162 associated gruop averages. The graphs are constructed as follows:
164 - X-axis represents performance trend job build Id (csit-vpp-perf-mrr-
166 - Y-axis represents MRR throughput in Mpps.
167 - Markers to indicate anomaly classification:
169 - Regression - red circle.
170 - Progression - green circle.
172 - The line shows average of each group.
174 In addition the graphs show dynamic labels while hovering over graph
175 data points, representing (trend job build Id, MRR value) and the actual
176 vpp build number (b<XXX>) tested.
182 Performance Trending (PT)
183 `````````````````````````
185 CSIT PT runs regular performance test jobs measuring and collecting MRR
186 data per test case. PT is designed as follows:
190 a) Periodic e.g. daily.
191 b) On-demand gerrit triggered.
193 2. Measurements and data calculations per test case:
195 a) Max Received Rate (MRR) - send packets at link rate over a trial
196 period, count total received packets, divide by trial period.
198 3. Archive MRR per test case.
199 4. Archive all counters collected at MRR.
201 Performance Analysis (PA)
202 `````````````````````````
204 CSIT PA runs performance analysis including trendline calculation, trend
205 compliance and anomaly detection using specified trend analysis metrics
206 over the rolling window of last <N> sets of historical measurement data.
207 PA is defined as follows:
211 a) By PT job at its completion.
212 b) On-demand gerrit triggered.
214 2. Download and parse archived historical data and the new data:
216 a) Download RF output.xml files from latest PT job and compressed
218 b) Parse out the data filtering test cases listed in PA specification
219 (part of CSIT PAL specification file).
221 3. Re-calculate new groups and their averages.
223 4. Evaluate new test data:
225 a) If the existing group is prolonged => Result = Pass,
226 Reason = Normal. (to be updated base on the final Jenkins code).
227 b) If a new group is detected with lower average => Result = Fail, Reason = Regression.
228 c) If a new group is detected with higher average => Result = Pass, Reason = Progression.
230 5. Generate and publish results
232 a) Relay evaluation result to job result. (to be updated base on the
234 b) Generate a new set of trend summary dashboard and graphs.
235 c) Publish trend dashboard and graphs in html format on
238 Testbed HW configuration
239 ------------------------
241 The testbed HW configuration is described on
242 `this FD.IO wiki page <https://wiki.fd.io/view/CSIT/CSIT_LF_testbed#FD.IO_CSIT_testbed_-_Server_HW_Configuration>`_.
244 .. _Minimum Description Length: https://en.wikipedia.org/wiki/Minimum_description_length
245 .. _Occam's razor: https://en.wikipedia.org/wiki/Occam%27s_razor
246 .. _bimodal distribution: https://en.wikipedia.org/wiki/Bimodal_distribution
Code Review / csit.git / blob