diff options
| author |   Vratko Polak <vrpolak@cisco.com> | 2022-07-20 10:18:29 +0200 |
|---|---|---|
| committer | Vratko Polak <vrpolak@cisco.com> | 2022-07-20 10:18:29 +0200 |
| commit | b06a1adb1c26eeb5bf5c86091fef30441f6d06a1 (patch) | |
| tree | 74c1139c3fd8412fd39185b75b07b230f2415f79 /docs/report | |
| parent | 371bac71bc789bf9d68fa1b8ba77f21c4876244f (diff) | |
fix(astf): avoid issues in pps tput
When more than 1 data packet is sent in the same chunk,
TRex is sometimes not fully deterministic
in its usage of delayed ACKs.
This changes the "application protocol" to sent
5 chunks (1 data packet each), c2s and s2c interleaved,
so each subsequent chunk acts as an ACK.
The overall packet count remains the same,
and even though this interleaved way may be more demanding
on TRex CPU, preliminary results show NAT performance
is still well below ip4base performance.
As a side effect, the interleaved way seems to work
also for 100B data frames, so we are avoiding two issues at once.
Ticket: CSIT-1846
Ticket: CSIT-1830
Change-Id: Ia4dcfa7c89f2c08fc32bd6118e2e009316b33c25
Signed-off-by: Vratko Polak <vrpolak@cisco.com>
Diffstat (limited to 'docs/report')
| -rw-r--r-- | docs/report/introduction/methodology_nat44.rst | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/docs/report/introduction/methodology_nat44.rst b/docs/report/introduction/methodology_nat44.rst index fb4cbd0c7e..1b00ef281c 100644 --- a/docs/report/introduction/methodology_nat44.rst +++ b/docs/report/introduction/methodology_nat44.rst @@ -416,6 +416,9 @@ TCP TPUT This profile uses a small transaction of "request-response" type, with some data amount to be transferred both ways. +In CSIT release 22.06, TRex behavior changed, so we needed to edit +the traffic profile. Let us describe the pre-22.06 profile first. + Client connects, sends 5 data packets worth of data, receives 5 data packets worth of data and closes its side of the connection. Server accepts connection, reads 5 data packets worth of data, @@ -449,6 +452,19 @@ and somehow uneven rate of packets sent. This makes it hard to interpret MRR results (frequently MRR is below NDR for this reason), but NDR and PDR results tend to be stable enough. +In 22.06, the "ACK from the receiving side" behavior changed, +the receiving side started sending ACK sometimes +also before receiving the full set of 5 data packets. +If the previous profile is understood as a "single challenge, single response" +where challenge (and also response) is sent as a burst of 5 data packets, +the new profile uses "bursts" of 1 packet instead, but issues +the challenge-response part 5 times sequentially +(waiting for receiving the response before sending next challenge). +This new profile happens to have the same overall packet count +(when no re-transmissions are needed). +Although it is possibly more taxing for TRex CPU, +the results are comparable to the old traffic profile. + Ip4base tests ^^^^^^^^^^^^^ |