diff options
Diffstat (limited to 'docs')
16 files changed, 81 insertions, 81 deletions
diff --git a/docs/report/introduction/methodology_autogen.rst b/docs/report/introduction/methodology_autogen.rst index 1bf5e9e5ea..5453775b7a 100644 --- a/docs/report/introduction/methodology_autogen.rst +++ b/docs/report/introduction/methodology_autogen.rst @@ -23,7 +23,7 @@ The generated suites (and their contents) are affected by multiple information sources, listed below. Git Suites ----------- +`````````` The suites present in git repository act as templates for generating suites. One of autogen design principles is that any template suite should also act @@ -33,7 +33,7 @@ In practice, autogen always re-creates the template suite with exactly the same content, it is one of checks that autogen works correctly. Regenerate Script ------------------ +````````````````` Not all suites present in CSIT git repository act as template for autogen. The distinction is on per-directory level. Directories with @@ -44,13 +44,13 @@ The script also specifies minimal frame size, indirectly, by specifying protocol (protocol "ip4" is the default, leading to 64B frame size). Constants ---------- +````````` Values in Constants.py are taken into consideration when generating suites. The values are mostly related to different NIC models and NIC drivers. Python Code ------------ +``````````` Python code in resources/libraries/python/autogen contains several other information sources. @@ -89,7 +89,7 @@ Some information sources are available in CSIT repository, but do not affect the suites generated by autogen. Testbeds --------- +```````` Overall, no information visible in topology yaml files is taken into account by autogen. @@ -121,7 +121,7 @@ Autogen does not care, as suites are agnostic. Robot tag marks the difference, but the link presence is not explicitly checked. Job specs ---------- +````````` Information in job spec files depend on generated suites (not the other way). Autogen should generate more suites, as job spec is limited by time budget. @@ -129,7 +129,7 @@ More suites should be available for manually triggered verify jobs, so autogen covers that. Bootstrap Scripts ------------------ +````````````````` Historically, bootstrap scripts perform some logic, perhaps adding exclusion options to Robot invocation diff --git a/docs/report/introduction/methodology_data_plane_throughput/index.rst b/docs/report/introduction/methodology_data_plane_throughput/index.rst index 487d300b5b..e2e373c56f 100644 --- a/docs/report/introduction/methodology_data_plane_throughput/index.rst +++ b/docs/report/introduction/methodology_data_plane_throughput/index.rst @@ -1,5 +1,5 @@ Data Plane Throughput -===================== +--------------------- .. toctree:: diff --git a/docs/report/introduction/methodology_data_plane_throughput/methodology_data_plane_throughput.rst b/docs/report/introduction/methodology_data_plane_throughput/methodology_data_plane_throughput.rst index a26b40088b..24e76ef391 100644 --- a/docs/report/introduction/methodology_data_plane_throughput/methodology_data_plane_throughput.rst +++ b/docs/report/introduction/methodology_data_plane_throughput/methodology_data_plane_throughput.rst @@ -1,7 +1,7 @@ .. _data_plane_throughput: Data Plane Throughput Tests ---------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^ Network data plane throughput is measured using multiple test methods in order to obtain representative and repeatable results across the large @@ -21,10 +21,10 @@ Description of each test method is followed by generic test properties shared by all methods. MLRsearch Tests -^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~ Description -~~~~~~~~~~~ +``````````` Multiple Loss Ratio search (MLRsearch) tests discover multiple packet throughput rates in a single search, reducing the overall test execution @@ -35,7 +35,7 @@ and Partial Drop Rate (PDR, with PLR<0.5%). MLRsearch is compliant with :rfc:`2544`. Usage -~~~~~ +````` MLRsearch tests are run to discover NDR and PDR rates for each VPP and DPDK release covered by CSIT report. Results for small frame sizes @@ -50,17 +50,17 @@ all frame sizes and for all tests are presented in detailed results tables. Details -~~~~~~~ +``````` See :ref:`mlrsearch_algorithm` section for more detail. MLRsearch is being standardized in IETF in `draft-ietf-bmwg-mlrsearch <https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-mlrsearch-01>`_. MRR Tests -^^^^^^^^^ +~~~~~~~~~ Description -~~~~~~~~~~~ +``````````` Maximum Receive Rate (MRR) tests are complementary to MLRsearch tests, as they provide a maximum “raw” throughput benchmark for development and @@ -72,7 +72,7 @@ a set trial duration, regardless of packet loss. Maximum load for specified Ethernet frame size is set to the bi-directional link rate. Usage -~~~~~ +````` MRR tests are much faster than MLRsearch as they rely on a single trial or a small set of trials with very short duration. It is this property @@ -86,7 +86,7 @@ comparisons between releases and test environments. Small frame sizes only (64b/78B, IMIX). Details -~~~~~~~ +``````` See :ref:`mrr_throughput` section for more detail about MRR tests configuration. @@ -98,10 +98,10 @@ and `VPP per patch tests <https://s3-docs.fd.io/csit/master/trending/methodology/perpatch_performance_tests.html>`_. PLRsearch Tests -^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~ Description -~~~~~~~~~~~ +``````````` Probabilistic Loss Ratio search (PLRsearch) tests discovers a packet throughput rate associated with configured Packet Loss Ratio (PLR) @@ -110,7 +110,7 @@ testing. PLRsearch assumes that system under test is probabilistic in nature, and not deterministic. Usage -~~~~~ +````` PLRsearch are run to discover a sustained throughput for PLR=10^-7 (close to NDR) for VPP release covered by CSIT report. Results for small @@ -121,14 +121,14 @@ Each soak test lasts 30 minutes and is executed at least twice. Results are compared against NDR and PDR rates discovered with MLRsearch. Details -~~~~~~~ +``````` See :ref:`plrsearch` methodology section for more detail. PLRsearch is being standardized in IETF in `draft-vpolak-bmwg-plrsearch <https://tools.ietf.org/html/draft-vpolak-bmwg-plrsearch>`_. Generic Test Properties -^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~ All data plane throughput test methodologies share following generic properties: diff --git a/docs/report/introduction/methodology_data_plane_throughput/methodology_mlrsearch_tests.rst b/docs/report/introduction/methodology_data_plane_throughput/methodology_mlrsearch_tests.rst index 6789dc073b..f834ca3e1b 100644 --- a/docs/report/introduction/methodology_data_plane_throughput/methodology_mlrsearch_tests.rst +++ b/docs/report/introduction/methodology_data_plane_throughput/methodology_mlrsearch_tests.rst @@ -1,7 +1,7 @@ .. _mlrsearch_algorithm: MLRsearch Tests ---------------- +^^^^^^^^^^^^^^^ Overview ~~~~~~~~ diff --git a/docs/report/introduction/methodology_data_plane_throughput/methodology_mrr_throughput.rst b/docs/report/introduction/methodology_data_plane_throughput/methodology_mrr_throughput.rst index 4e8000b161..f2a6cd57cd 100644 --- a/docs/report/introduction/methodology_data_plane_throughput/methodology_mrr_throughput.rst +++ b/docs/report/introduction/methodology_data_plane_throughput/methodology_mrr_throughput.rst @@ -1,7 +1,7 @@ .. _mrr_throughput: MRR Throughput --------------- +^^^^^^^^^^^^^^ Maximum Receive Rate (MRR) tests are complementary to MLRsearch tests, as they provide a maximum "raw" throughput benchmark for development and diff --git a/docs/report/introduction/methodology_data_plane_throughput/methodology_plrsearch.rst b/docs/report/introduction/methodology_data_plane_throughput/methodology_plrsearch.rst index d60e9203ff..a128674384 100644 --- a/docs/report/introduction/methodology_data_plane_throughput/methodology_plrsearch.rst +++ b/docs/report/introduction/methodology_data_plane_throughput/methodology_plrsearch.rst @@ -1,7 +1,7 @@ .. _plrsearch: PLRsearch ---------- +^^^^^^^^^ Motivation for PLRsearch ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -25,7 +25,7 @@ draft `draft-vpolak-bmwg-plrsearch-02`_ that is in the process of being standardized in the IETF Benchmarking Methodology Working Group (BMWG). Terms ------ +````` The rest of this page assumes the reader is familiar with the following terms defined in the IETF draft: @@ -319,7 +319,7 @@ low quality estimate at first sight, but a more detailed look reveals the quality is good (considering the measurement results). L2 patch --------- +________ Both fitting functions give similar estimates, the graph shows "stochasticity" of measurements (estimates increase and decrease @@ -356,7 +356,7 @@ the performance stays constant. :align: center Vhost ------ +_____ This test case shows what looks like a quite broad estimation interval, compared to other test cases with similarly looking zero loss frequencies. @@ -390,7 +390,7 @@ agrees that the interval should be wider than that. :align: center Summary -------- +_______ The two graphs show the behavior of PLRsearch algorithm applied to soaking test when some of PLRsearch assumptions do not hold: diff --git a/docs/report/introduction/methodology_dut_state.rst b/docs/report/introduction/methodology_dut_state.rst index d08e42513d..3792e31ecf 100644 --- a/docs/report/introduction/methodology_dut_state.rst +++ b/docs/report/introduction/methodology_dut_state.rst @@ -1,5 +1,5 @@ DUT state considerations ------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^ This page discusses considerations for Device Under Test (DUT) state. DUTs such as VPP require configuration, to be provided before the aplication @@ -42,7 +42,7 @@ As the performance is different, each test has to choose which traffic it wants to test, and manipulate the DUT state to achieve the intended impact. Ramp-up trial -_____________ +````````````` Tests aiming at sustain performance need to make sure DUT state is created. We achieve this via a ramp-up trial, specific purpose of which @@ -67,7 +67,7 @@ it has been created as expected. Test fails if the state is not (completely) created. State Reset -___________ +``````````` Tests aiming at ramp-up performance do not use ramp-up trial, and they need to reset the DUT state before each trial measurement. @@ -94,7 +94,7 @@ If neither were used, DUT will show different performance in subsequent trials, violating assumptions of search algorithms. DUT versus protocol ramp-up -___________________________ +``````````````````````````` There are at least three different causes for bandwidth possibly increasing within a single measurement trial. diff --git a/docs/report/introduction/methodology_nat44.rst b/docs/report/introduction/methodology_nat44.rst index 1b00ef281c..7dfd939ecc 100644 --- a/docs/report/introduction/methodology_nat44.rst +++ b/docs/report/introduction/methodology_nat44.rst @@ -1,10 +1,10 @@ .. _nat44_methodology: Network Address Translation IPv4 to IPv4 ----------------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NAT44 Prefix Bindings -^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~ NAT44 prefix bindings should be representative to target applications, where a number of private IPv4 addresses from the range defined by @@ -67,7 +67,7 @@ Private address ranges to be used in tests: - Used in tests for up to 1 048 576 inside addresses (inside hosts). NAT44 Session Scale -~~~~~~~~~~~~~~~~~~~ +``````````````````` NAT44 session scale tested is govern by the following logic: @@ -95,7 +95,7 @@ NAT44 session scale tested is govern by the following logic: +---+---------+------------+ NAT44 Deterministic -^^^^^^^^^^^^^^^^^^^ +``````````````````` NAT44det performance tests are using TRex STL (Stateless) API and traffic profiles, similar to all other stateless packet forwarding tests like @@ -134,7 +134,7 @@ NAT44det scenario tested: TODO: Make traffic profile names resemble suite names more closely. NAT44 Endpoint-Dependent -^^^^^^^^^^^^^^^^^^^^^^^^ +```````````````````````` In order to excercise NAT44ed ability to translate based on both source and destination address and port, the inside-to-outside traffic @@ -200,13 +200,13 @@ NAT44det case tested: - [mrr|ndrpdr|soak], bidirectional stateful tests MRR, NDRPDR, or SOAK. Stateful traffic profiles -^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~ There are several important details which distinguish ASTF profiles from stateless profiles. General considerations -~~~~~~~~~~~~~~~~~~~~~~ +`````````````````````` Protocols _________ @@ -347,7 +347,7 @@ does not match the transactions as defined by ASTF programs. See TCP TPUT profile below. UDP CPS -~~~~~~~ +``````` This profile uses a minimalistic transaction to verify NAT44ed session has been created and it allows outside-to-inside traffic. @@ -362,7 +362,7 @@ Transaction counts as attempted when opackets counter increases on client side. Transaction counts as successful when ipackets counter increases on client side. TCP CPS -~~~~~~~ +``````` This profile uses a minimalistic transaction to verify NAT44ed session has been created and it allows outside-to-inside traffic. @@ -386,7 +386,7 @@ Transaction counts as successful when tcps_connects counter increases on client side. UDP TPUT -~~~~~~~~ +```````` This profile uses a small transaction of "request-response" type, with several packets simulating data payload. @@ -411,7 +411,7 @@ in the reading phase. This probably decreases TRex performance, but it leads to more stable results then alternatives. TCP TPUT -~~~~~~~~ +```````` This profile uses a small transaction of "request-response" type, with some data amount to be transferred both ways. @@ -466,7 +466,7 @@ Although it is possibly more taxing for TRex CPU, the results are comparable to the old traffic profile. Ip4base tests -^^^^^^^^^^^^^ +~~~~~~~~~~~~~ Contrary to stateless traffic profiles, we do not have a simple limit that would guarantee TRex is able to send traffic at specified load. diff --git a/docs/report/introduction/methodology_packet_flow_ordering.rst b/docs/report/introduction/methodology_packet_flow_ordering.rst index 3796b21796..47118f971c 100644 --- a/docs/report/introduction/methodology_packet_flow_ordering.rst +++ b/docs/report/introduction/methodology_packet_flow_ordering.rst @@ -11,7 +11,7 @@ altered, in some cases two fields (e.g. IPv4 destination address and UDP destination port) are altered. Incremental Ordering --------------------- +~~~~~~~~~~~~~~~~~~~~ This case is simpler to implement and offers greater control. @@ -24,7 +24,7 @@ combinations once before the "carry" field also wraps around. It is possible to use increments other than 1. Randomized Ordering -------------------- +~~~~~~~~~~~~~~~~~~~ This case chooses each field value at random (from the allowed range). In case of two fields, they are treated independently. diff --git a/docs/report/introduction/methodology_packet_latency.rst b/docs/report/introduction/methodology_packet_latency.rst index 35e2aad029..cd11663eaf 100644 --- a/docs/report/introduction/methodology_packet_latency.rst +++ b/docs/report/introduction/methodology_packet_latency.rst @@ -1,7 +1,7 @@ .. _latency_methodology: Packet Latency --------------- +^^^^^^^^^^^^^^ TRex Traffic Generator (TG) is used for measuring one-way latency in 2-Node and 3-Node physical testbed topologies. TRex integrates `High diff --git a/docs/report/introduction/methodology_rca/methodology_perpatch_performance_tests.rst b/docs/report/introduction/methodology_rca/methodology_perpatch_performance_tests.rst index 97c5e091ff..311fac456b 100644 --- a/docs/report/introduction/methodology_rca/methodology_perpatch_performance_tests.rst +++ b/docs/report/introduction/methodology_rca/methodology_perpatch_performance_tests.rst @@ -8,7 +8,7 @@ before a DUT code change is merged. This can act as a verify job to disallow changes which would decrease performance without a good reason. Existing jobs -````````````` +~~~~~~~~~~~~~ VPP is the only project currently using such jobs. They are not started automatically, must be triggered on demand. @@ -21,7 +21,7 @@ where the node_arch combinations currently supported are: 2n-clx, 2n-dnv, 2n-tx2, 2n-zn2, 3n-dnv, 3n-tsh. Test selection --------------- +~~~~~~~~~~~~~~ .. TODO: Majority of this section is also useful for CSIT verify jobs. Move it somewhere. @@ -37,7 +37,7 @@ What follows is a list of explanations and recommendations to help users to select the minimal set of tests cases. Verify cycles -_____________ +````````````` When Gerrit schedules multiple jobs to run for the same patch set, it waits until all runs are complete. @@ -55,7 +55,7 @@ that comment gets ignored by Jenkins. Only when 3n-icx job finishes, the user can trigger 2n-icx. One comment many jobs -_____________________ +````````````````````` In the past, the CSIT code which parses for perftest trigger comments was buggy, which lead to bad behavior (as in selection all performance test, @@ -66,7 +66,7 @@ The worst bugs were fixed since then, but it is still recommended to use just one trigger word per Gerrit comment, just to be safe. Multiple test cases in run -__________________________ +`````````````````````````` While Robot supports OR operator, it does not support parentheses, so the OR operator is not very useful. It is recommended @@ -78,7 +78,7 @@ perftest-2n-icx {tag_expression_1} {tag_expression_2} See below for more concrete examples. Suite tags -__________ +`````````` Traditionally, CSIT maintains broad Robot tags that can be used to select tests, for details on existing tags, see @@ -101,7 +101,7 @@ and user still probably wants to narrow down to a single test case within a suite. Fully specified tag expressions -_______________________________ +``````````````````````````````` Here is one template to select a single test case: {test_type}AND{nic_model}AND{nic_driver}AND{cores}AND{frame_size}AND{suite_tag} @@ -130,7 +130,7 @@ for example `this one <https://github.com/FDio/csit/blob/master/docs/job_specs/r TODO: Explain why "periodic" job spec link lands at report_iterative. Shortening triggers -___________________ +``````````````````` Advanced users may use the following tricks to avoid writing long trigger comments. @@ -151,7 +151,7 @@ will fail, as the default nic_model is nic_intel-xxv710 which does not support RDMA core driver. Complete example -________________ +```````````````` A user wants to test a VPP change which may affect load balance whith bonding. Searching tag documentation for "bonding" finds LBOND tag and its variants. @@ -179,7 +179,7 @@ After shortening, this is the trigger comment fianlly used: perftest-3n-icx mrrANDnic_intel-x710AND1cAND64bAND?lbvpplacp-dot1q-l2xcbase-eth-2vhostvr1024-1vm*NOTdrv_af_xdp Basic operation -``````````````` +~~~~~~~~~~~~~~~ The job builds VPP .deb packages for both the patch under test (called "current") and its parent patch (called "parent"). @@ -199,7 +199,7 @@ The whole job fails (giving -1) if some trial measurement failed, or if any test was declared a regression. Temporary specifics -``````````````````` +~~~~~~~~~~~~~~~~~~~ The Minimal Description Length analysis is performed by CSIT code equivalent to jumpavg-0.1.3 library available on PyPI. @@ -216,7 +216,7 @@ This decreases sensitivity to regressions, but also decreases probability of false positives. Console output -`````````````` +~~~~~~~~~~~~~~ The following information as visible towards the end of Jenkins console output, repeated for each analyzed test. diff --git a/docs/report/introduction/methodology_reconf.rst b/docs/report/introduction/methodology_reconf.rst index 1a1f4cc98c..976cd7a6a3 100644 --- a/docs/report/introduction/methodology_reconf.rst +++ b/docs/report/introduction/methodology_reconf.rst @@ -1,7 +1,7 @@ .. _reconf_tests: Reconfiguration Tests ---------------------- +^^^^^^^^^^^^^^^^^^^^^ .. important:: diff --git a/docs/report/introduction/methodology_trending/index.rst b/docs/report/introduction/methodology_trending/index.rst index 9105ec46b4..957900226b 100644 --- a/docs/report/introduction/methodology_trending/index.rst +++ b/docs/report/introduction/methodology_trending/index.rst @@ -1,5 +1,5 @@ Trending Methodology -==================== +-------------------- .. toctree:: diff --git a/docs/report/introduction/methodology_trending/trend_analysis.rst b/docs/report/introduction/methodology_trending/trend_analysis.rst index 2bb54997b0..20ad46405a 100644 --- a/docs/report/introduction/methodology_trending/trend_analysis.rst +++ b/docs/report/introduction/methodology_trending/trend_analysis.rst @@ -22,7 +22,7 @@ Implementation details ~~~~~~~~~~~~~~~~~~~~~~ Partitioning into groups ------------------------- +```````````````````````` While sometimes the samples within a group are far from being distributed normally, currently we do not have a better tractable model. @@ -39,7 +39,7 @@ results). The group boundaries are selected based on `Minimum Description Length`_. Minimum Description Length --------------------------- +`````````````````````````` `Minimum Description Length`_ (MDL) is a particular formalization of `Occam's razor`_ principle. @@ -103,7 +103,7 @@ We are going to describe the behaviors, as they motivate our choice of trend compliance metrics. Sample time and analysis time ------------------------------ +````````````````````````````` But first we need to distinguish two roles time plays in analysis, so it is more clear which role we are referring to. @@ -132,7 +132,7 @@ so the values reported there are likely to be different from the later analysis time results shown in dashboard and graphs. Ordinary regression -------------------- +``````````````````` The real performance changes from previously stable value into a new stable value. @@ -143,7 +143,7 @@ is enough for anomaly detection to mark this regression. Ordinary progressions are detected in the same way. Small regression ----------------- +```````````````` The real performance changes from previously stable value into a new stable value, but the difference is small. @@ -162,7 +162,7 @@ is still not enough for the detection). Small progressions have the same behavior. Reverted regression -------------------- +``````````````````` This pattern can have two different causes. We would like to distinguish them, but that is usually @@ -196,7 +196,7 @@ to increase performance, the opposite (temporary progression) almost never happens. Summary -------- +``````` There is a trade-off between detecting small regressions and not reporting the same old regressions for a long time. diff --git a/docs/report/introduction/methodology_trending/trend_presentation.rst b/docs/report/introduction/methodology_trending/trend_presentation.rst index 67d0d3c45a..7272ac6e38 100644 --- a/docs/report/introduction/methodology_trending/trend_presentation.rst +++ b/docs/report/introduction/methodology_trending/trend_presentation.rst @@ -8,7 +8,7 @@ The Failed tests tables list the tests which failed during the last test run. Separate tables are generated for each testbed. Regressions and progressions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These tables list tests which encountered a regression or progression during the specified time period, which is currently set to the last 21 days. diff --git a/docs/report/introduction/methodology_trex_traffic_generator.rst b/docs/report/introduction/methodology_trex_traffic_generator.rst index 180e3dda8c..02b46e0180 100644 --- a/docs/report/introduction/methodology_trex_traffic_generator.rst +++ b/docs/report/introduction/methodology_trex_traffic_generator.rst @@ -1,5 +1,5 @@ TRex Traffic Generator ----------------------- +^^^^^^^^^^^^^^^^^^^^^^ Usage ~~~~~ @@ -18,7 +18,7 @@ Traffic modes TRex is primarily used in two (mutually incompatible) modes. Stateless mode -______________ +`````````````` Sometimes abbreviated as STL. A mode with high performance, which is unable to react to incoming traffic. @@ -32,7 +32,7 @@ Measurement results are based on simple L2 counters (opackets, ipackets) for each traffic direction. Stateful mode -_____________ +````````````` A mode capable of reacting to incoming traffic. Contrary to the stateless mode, only UDP and TCP is supported @@ -57,7 +57,7 @@ Generated traffic is either continuous, or limited (by number of transactions). Both modes support both continuities in principle. Continuous traffic -__________________ +`````````````````` Traffic is started without any data size goal. Traffic is ended based on time duration, as hinted by search algorithm. @@ -65,7 +65,7 @@ This is useful when DUT behavior does not depend on the traffic duration. The default for stateless mode. Limited traffic -_______________ +``````````````` Traffic has defined data size goal (given as number of transactions), duration is computed based on this goal. @@ -83,14 +83,14 @@ Traffic can be generated synchronously (test waits for duration) or asynchronously (test operates during traffic and stops traffic explicitly). Synchronous traffic -___________________ +``````````````````` Trial measurement is driven by given (or precomputed) duration, no activity from test driver during the traffic. Used for most trials. Asynchronous traffic -____________________ +```````````````````` Traffic is started, but then the test driver is free to perform other actions, before stopping the traffic explicitly. @@ -109,7 +109,7 @@ Search algorithms are intentionally unaware of the traffic mode used, so CSIT defines some terms to use instead of mode-specific TRex terms. Transactions -____________ +```````````` TRex traffic profile defines a small number of behaviors, in CSIT called transaction templates. Traffic profiles also instruct @@ -130,7 +130,7 @@ Thus unidirectional stateless profiles define one transaction template, bidirectional stateless profiles define two transaction templates. TPS multiplier -______________ +`````````````` TRex aims to open transaction specified by the profile at a steady rate. While TRex allows the transaction template to define its intended "cps" value, @@ -145,7 +145,7 @@ set "packets per transaction" value to 2, just to keep the TPS semantics as a unidirectional input value. Duration stretching -___________________ +``````````````````` TRex can be IO-bound, CPU-bound, or have any other reason why it is not able to generate the traffic at the requested TPS. @@ -175,7 +175,7 @@ so that users can compare results. If the results are very similar, it is probable TRex was the bottleneck. Startup delay -_____________ +````````````` By investigating TRex behavior, it was found that TRex does not start the traffic in ASTF mode immediately. There is a delay of zero traffic, |