- The maximum forwarding rate in Frames Per Second (FPS) and Mbps of the DUT for each frame size with X% packet loss and packet modification operations being performed by the DUT.
- The average latency of the traffic flow when passing through the DUT (if testing for latency, note that this average is different from the test specified in Section 26.3 of [RFC2544]).
- The [RFC5481] PDV form of delay variation on the traffic flow, using the 99th percentile.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2544.SystemRecoveryTime
+ **Title**: RFC 2544 System Recovery Time Test
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to determine the length of time it takes the DUT to recover from an overload condition for a constant load (fixed length frames at a fixed interval time). The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams), traffic should be sent to the DUT under normal conditions. During the duration of the test and while the traffic flows are passing though the DUT, at least one situation leading to an overload condition for the DUT should occur. The time from the start of the overload condition to when the DUT returns to normal operations should be measured to determine recovery time. Prior to overloading the DUT, one should record the average latency for 100 packets forwarded through the DUT.
+
+ The suggested overload condition would be to transmit traffic at a very high frame rate to the DUT, for at least 60 seconds, then reduce the frame rate to the DUT by half; A number of time-stamps should be recorded:
+ - Record the time-stamp at which the frame rate was halved and record a second time-stamp at the time of the last frame lost. The recovery time is the difference between the two timestamps.
+ - Record the average Latency for 100 frames after the last frame loss and continue to record average latency measurements for every 100 frames, when latency returns to pre-overload levels record the time-stamp.
+
+ **Expected Result**:
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+
+ - The length of time it takes the DUT to recover from an overload condition.
+ - The length of time it takes the DUT to recover the average latency to pre-overload conditions.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
<br/>
+ - #####Test ID: LTD.Throughput.RFC2544.BackToBackFrames
+ **Title**: RFC 2544 Back To Back Frames Test
+
+ **Prerequisite Test**: N\A
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to characterize the ability of the DUT to process back-to-back frames. For each frame size previously defined under [Default Test Parameters](#DefaultParams), a burst of traffic is sent to the DUT with the minimum inter-frame gap between each frame. If the number of received frames equals the number of frames that were transmitted, the burst size should be increased and traffic is sent to the DUT again. The value measured is the back-to-back value, that is the maximum burst size the DUT can handle without any frame loss.
+
+ **Expected Result**:
+ Tests of back-to-back frames with physical devices have produced unstable results in some cases. All tests should be repeated in multiple test sessions and results stability should be examined.
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+
+ - The back-to-back value, which is the the number of frames in the longest burst that the DUT will handle without the loss of any frames.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
[RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt)
[RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt)
[RFC5481]:(http://www.ietf.org/rfc/rfc5481.txt)
Code Review / vswitchperf.git / blobdiff