report: add 2n-icx and 3n-icx testbed documentation

[csit.git] / docs / report / introduction / methodology_packet_latency.rst

diff --git a/docs/report/introduction/methodology_packet_latency.rst b/docs/report/introduction/methodology_packet_latency.rst
index 550d12f..35e2aad 100644 (file)
--- a/docs/report/introduction/methodology_packet_latency.rst
+++ b/docs/report/introduction/methodology_packet_latency.rst
@@ -1,23 +1,43 @@
+.. _latency_methodology:
+
 Packet Latency
 --------------
 
-TRex Traffic Generator (TG) is used for measuring latency of VPP DUTs.
-Reported latency values are measured using following methodology:
+TRex Traffic Generator (TG) is used for measuring one-way latency in
+2-Node and 3-Node physical testbed topologies. TRex integrates `High
+Dynamic Range Histogram (HDRH) <http://hdrhistogram.org/>`_
+functionality and reports per packet latency distribution for latency
+streams sent in parallel to the main load packet streams.
+
+Following methodology is used:
+
+- Only NDRPDR test type measures latency and only after NDR and PDR
+  values are determined. Other test types do not involve latency
+  streams.
+- Latency is measured at different background load packet rates:
+
+  - No-Load: latency streams only.
+  - Low-Load: at 10% PDR.
+  - Mid-Load: at 50% PDR.
+  - High-Load: at 90% PDR.
 
-- Latency tests are performed at 100% of discovered NDR and PDR rates
-  for each throughput test and packet size (except IMIX).
+- Latency is measured for all tested packet sizes except IMIX due to
+  TRex TG restriction.
 - TG sends dedicated latency streams, one per direction, each at the
   rate of 9 kpps at the prescribed packet size; these are sent in
   addition to the main load streams.
-- TG reports min/avg/max latency values per stream direction, hence two
-  sets of latency values are reported per test case; future release of
-  TRex is expected to report latency percentiles.
-- Reported latency values are aggregate across two SUTs due to three
-  node topology used for all performance tests; for per SUT latency,
-  reported value should be divided by two.
-- 1usec is the measurement accuracy advertised by TRex TG for the setup
-  used in FD.io labs used by CSIT project.
-- TRex setup introduces an always-on error of about 2*2usec per latency
-  flow additonal Tx/Rx interface latency induced by TRex SW writing and
-  reading packet timestamps on CPU cores without HW acceleration on NICs
-  closer to the interface line.
+- TG reports Min/Avg/Max and HDRH latency values distribution per stream
+  direction, hence two sets of latency values are reported per test case
+  (marked as E-W and W-E).
+- +/- 1 usec is the measurement accuracy of TRex TG and the data in HDRH
+  latency values distribution is rounded to microseconds.
+- TRex TG introduces a (background) always-on Tx + Rx latency bias of 4
+  usec on average per direction resulting from TRex software writing and
+  reading packet timestamps on CPU cores. Quoted values are based on TG
+  back-to-back latency measurements.
+- Latency graphs are not smoothed, each latency value has its own
+  horizontal line across corresponding packet percentiles.
+- Percentiles are shown on X-axis using a logarithmic scale, so the
+  maximal latency value (ending at 100% percentile) would be in
+  infinity. The graphs are cut at 99.9999% (hover information still
+  lists 100%).
\ No newline at end of file