- Any outliers in the Throughput stability.
- Any unexpected variation in Throughput stability.
+<br/>
+
+ - #####Test ID: LTD.Throughput.RFC6201.ResetTime
+ **Title**: RFC 6201 Reset 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 a reset. For each frame size 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 through the DUT, the DUT should be reset and the Reset time measured. The Reset time is the total time that a device is determined to be out of operation and includes the time to perform the reset and the time to recover from it (cf. [RFC6201])
+
+ [RFC6201] defines two methods to measure the Reset time:
+ - Frame-Loss Method: which requires the monitoring of the number of lost frames and calculates the Reset time based on the number of frames lost and the offered rate according to the following formula:
+ <pre><code>
+ Frames_lost (packets)
+ Reset_time = -------------------------------------
+ Offered_rate (packets per second)
+ </code></pre>
+ - Timestamp Method: which measures the time from which the last frame is forwarded from the DUT to the time the first frame is forwarded after the reset. This involves time-stamping all transmitted frames and recording the timestamp of the last frame that was received prior to the reset and also measuring the timestamp of the first frame that is received after the reset. The Reset time is the difference between these two timestamps.
+
+ According to [RFC6201] the choice of method depends on the test tool's capability; the Frame-Loss method SHOULD be used if the test tool supports:
+ - Counting the number of lost frames per stream.
+ - Transmitting test frame despite the physical link status.
+
+ whereas the Timestamp method SHOULD be used if the test tool supports:
+ - Timestamping each frame.
+ - Monitoring received frame's timestamp.
+ - Transmitting frames only if the physical link status is up.
+
+ **Expected Result**:
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+ - Average Reset Time.
+
+ Results of this test should include the following information:
+ - Throughput in Fps and Mbps.
+ - Average Frame Loss.
+ - Average Reset Time in milliseconds.
+ - Number of trials.
+ - Protocol: IPv4, IPv6, MPLS, etc.
+ - Frame Size in Octets
+ - Port Media: Ethernet, Gigabit Ethernet (GbE), etc.
+ - Port Speed: 10 Gbps, 40 Gbps etc.
+ - Interface Encapsulation: Ethernet, Ethernet VLAN, etc.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
+<br/>
+
+ - #####Test ID: LTD.Throughput.RFC2889.ForwardingRate
+
+ **Title**: RFC2889 Forwarding Rate Test
+
+ **Prerequisite Test**: LTD.Throughput.RFC2544.PacketLossRatio
+
+ **Priority**:
+
+ **Description**:
+
+ This test measures the DUT's Max Forwarding Rate when the Offered Load is varied between the throughput and the Maximum Offered Load for fixed length frames at a fixed time interval. The selected frame sizes are those previously defined under [Default Test Parameters](#DefaultParams). The throughput is the maximum offered load with 0% frame loss (measured by the prerequisite test), and the Maximum Offered Load (as defined by [RFC2885]) is _"the highest number of frames per second that an external source can transmit to a DUT/SUT for forwarding to a specified output interface or interfaces"_.
+
+ Traffic should be sent to the DUT at a particular rate (TX rate) starting with TX rate equal to the throughput rate. The rate of successfully received frames at the destination counted (in FPS). If the RX rate is equal to the TX rate, the TX rate should be increased by a fixed step size and the RX rate measured again until the Max Forwarding Rate is found.
+
+ The trial duration for each iteration should last for the period of time needed for the system to reach steady state for the frame size being tested. Under [RFC2889] test methodology, the test duration should run for a minimum period of 30 seconds, regardless whether the system reaches steady state before the minimum duration ends.
+
+ **Expected Result**:
+ According to [RFC2889] The Max Forwarding Rate is the highest forwarding rate of a DUT taken from an iterative set of forwarding rate measurements. The iterative set of forwarding rate measurements are made by setting the intended load transmitted from an external source and measuring the offered load (i.e what the DUT is capable of forwarding). If the Throughput == the Maximum Offered Load, it follows that Max Forwarding Rate is equal to the Maximum Offered Load.
+
+ **Metrics Collected**:
+
+ The following are the metrics collected for this test:
+
+ - The Max Forwarding Rate for the DUT for each packet size.
+
+<br/>
+ - #####Test ID: LTD.Throughput.RFC2889.ForwardPressure
+ **Title**: RFC2889 Forward Pressure Test
+
+ **Prerequisite Test**: LTD.Throughput.RFC2889.ForwardingRate
+
+ **Priority**:
+
+ **Description**:
+
+ The aim of this test is to determine if the DUT transmits frames with an inter-frame gap that is less than 12 bytes. This test overloads the DUT and measures the output for forward pressure. Traffic should be transmitted to the DUT with an inter-frame gap of 11 bytes, this will overload the DUT by 1 byte per frame. The forwarding rate of the DUT should be measured.
+
+ **Expected Result**:
+ The forwarding rate should not exceed the maximum forwarding rate of the DUT collected by LTD.Throughput.RFC2889.ForwardingRate.
+
+ **Metrics collected**
+
+ The following are the metrics collected for this test:
+
+ - Forwarding rate of the DUT.
+
+ **Deployment scenario**:
+
+ - Physical → virtual switch → physical.
+
<br/>
[RFC1242]:(http://www.ietf.org/rfc/rfc1242.txt)
[RFC2544]:(http://www.ietf.org/rfc/rfc2544.txt)
+[RFC2885]:(http://www.ietf.org/rfc/rfc2885.txt)
+[RFC2889]:(http://www.ietf.org/rfc/rfc2889.txt)
[RFC5481]:(http://www.ietf.org/rfc/rfc5481.txt)
[RFC6201]:(http://www.ietf.org/rfc/rfc6201.txt)
[DPDK]:http://www.dpdk.org/
Code Review / vswitchperf.git / blobdiff