diff options
Diffstat (limited to 'test_spec/vswitchperf_ltd.md')
| -rw-r--r-- | test_spec/vswitchperf_ltd.md | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/test_spec/vswitchperf_ltd.md b/test_spec/vswitchperf_ltd.md index 05711b37..55015629 100644 --- a/test_spec/vswitchperf_ltd.md +++ b/test_spec/vswitchperf_ltd.md @@ -554,6 +554,36 @@ The following represents possible deployments which can help to determine the pe - 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/> [RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt) |