TRex Traffic Generator
-----------------------
+^^^^^^^^^^^^^^^^^^^^^^
Usage
~~~~~
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.
(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
This mode is suitable for NAT44ED tests, as clients send packets from inside,
and servers react to it, so they see the outside address and port to respond to.
-Also, they do not send traffic before NAT44ED has opened the sessions.
+Also, they do not send traffic before NAT44ED has created the corresponding
+translation entry.
When possible, L2 counters (opackets, ipackets) are used.
Some tests need L7 counters, which track protocol state (e.g. TCP),
-but the values are less than reliable on high loads.
+but those values are less than reliable on high loads.
Traffic Continuity
~~~~~~~~~~~~~~~~~~
-Generated traffic is either continuous, or limited.
+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 size goal.
-Traffic is ended based on time duration as hinted by search algorithm.
+Traffic is started without any data size goal.
+Traffic is ended based on time duration, as hinted by search algorithm.
This is useful when DUT behavior does not depend on the traffic duration.
The default for stateless mode.
Limited traffic
-_______________
+```````````````
-Traffic has defined size goal, duration is computed based on the goal.
+Traffic has defined data size goal (given as number of transactions),
+duration is computed based on this goal.
Traffic is ended when the size goal is reached,
or when the computed duration is reached.
This is useful when DUT behavior depends on traffic size,
-e.g. target number of session, each to be hit once.
+e.g. target number of NAT translation entries, each to be hit exactly once
+per direction.
This is used mainly for stateful mode.
Traffic synchronicity
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.
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
TRex how to create a large number of transactions based on the templates.
Continuous traffic loops over the generated transactions.
-Limited traffic usually executes each transaction once.
+Limited traffic usually executes each transaction once
+(typically as constant number of loops over source addresses,
+each loop with different source ports).
Currently, ASTF profiles define one transaction template each.
Number of packets expected per one transaction varies based on profile details,
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,
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.
In CSIT we decided to use logic similar to asynchronous traffic.
The traffic driver sleeps for a time, then stops the traffic explicitly.
The library that parses counters into measurement results
-than usually treats unsent packets as lost.
+than usually treats unsent packets/transactions as lost/failed.
We have added a IP4base tests for every NAT44ED test,
so that users can compare results.
-Of the results are very similar, it is probable TRex was the bottleneck.
+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,
to the computed duration so traffic is stopped after the intended
duration of real traffic. Luckily, it turns out this correction
is not dependend on traffic profile nor CPU used by TRex,
-so a fixed constant (0.1115 seconds) works well.
+so a fixed constant (0.112 seconds) works well.
+Unfortunately, the constant may depend on TRex version,
+or execution environment (e.g. TRex in AWS).
The result computations need a precise enough duration of the real traffic,
luckily server side of TRex has precise enough counter for that.
created (one for each direction) with TRex flow_stats parameter set to
STLFlowLatencyStats. In that case, returned statistics will also include
min/avg/max latency values and encoded HDRHistogram data.
+
+..
+ TODO: Mention we have added TRex self-test suites.
Code Review / csit.git / blobdiff