RFC Benchmark Test Results

After the test has finished running, Results Reporter displays the following test results:

To view pre-formatted results:

  1. In the left pane of Results Reporter, expand the Results tree to view all results database (.db) files that are currently loaded.

    The default name of a database file includes the date and time when the results were generated. For example, default-2007-02-06_09-57-37.db contains test results from February 6, 2007, at 9:57:37.

  2. If the desired results database (.db) file is not shown in the Results tree, use File > Open or click the Open Result Database button to bring up the Choose Result Database dialog box. Specify the desired results database file, and click Open.
  3. In the left pane, expand the tree for the desired database (.db) file. The tree includes a Test Result Summary View for each test saved in the file. The view is labeled with the icon to indicate that it is associated with the appropriate results template for the test. The template, which is automatically installed with Results Reporter, provides pre-defined formatting of the database file values.
  4. Select the desired Test Result Summary View. The right pane then displays the results.

To view summary tables of result values:

  1. In the left pane, expand the tree for the database file. An example is shown below.

  2. Click one of the tables, which are labeled with the icon, to display its result values in the right pane.
  3. To create a graph using the values in the selected table, click the Create Graph button . The Configure Graph window appears and displays the graph.

Description of RFC2544/RFC2889 Results Tables

Tables not listed below are legacy objects that do not contain relevant results.

Results Table Description
Rfc2544XPerLoadResult Summary results for each test iteration
Rfc2544ThroughputPerFrameSizeResult Summary results of the determined throughput load for each frame size
Rfc2544ThroughputPerFrameSizeResultByPort Intended load for each port as configured for the throughput iteration
Rfc2544ThroughputPerCoexistenceRatioResult Summary results of the determined throughput load for each ratio and frame size
Rfc2544FrameLossPerFrameSizeResult Summary results for the test iteration that caused the load loop to end (occurs after two lossless iterations)
Rfc2544FrameLossPerCoexistenceRatioResult Summary results for the test iteration that caused the load loop to end
Rfc2889AddrCachingPerAddrResult Summary results for each address size tested
Rfc2889AddrCachingPerPortResult Per port results for each test iteration
Rfc2889AddrLearningPerLearningRateResult Summary results for each learning rate used
Rfc2889AddrLearningPerPortResult Per port results for each test iteration
Rfc2889BroadcastFrameForwardingPerBurstSizeResult Summaries of the measured forwarding rate for each frame size, burst size tuple
Rfc2889BroadcastFrameForwardingPerLoadResult Summary results for each test iteration
Rfc2889BroadcastFrameLatencyPerFrameSizeResult Summary results for each iteration
Rfc2889BroadcastFrameLatencyPerFrameSizePerPortResult Per port results for each test iteration
Rfc2889CongestionControlPerLoadResult Summary results for each test iteration
Rfc2889CongestionControlPerPortResult Per port results for each test iteration
Rfc2889ErroredFramesFilteringPerLoadResult Summary results for each test iteration
Rfc2889ForwardingPerBurstSizeResult Summaries of the measured forwarding rate for each frame size, burst size tuple
Rfc2889ForwardingPerLoadResult Summary results for each test iteration
Rfc2889ForwardPressurePerFrameSizeResult Summary results for each test iteration
Rfc2889MaxForwardingRatePerLoadResult Summary results for each test iteration

Table of Units

The following metrics are reported in the indicated units.

Metric Unit
Frame Rate frames per second
Frame Size bytes
Frame size type Fixed, Step, Random, or iMIX
FRMOL OL frames per second
FRMOL FWD Rate frames per second
Intended Load Rate Specified during test configuration
Jitter microseconds
Latency microseconds
Latency Type LIFO, LILO, FIFO, FILO
MFR OL frames per second
MFR FWD Rate frames per second
Offered Load Specified during test configuration
Theoretical Maximum Frame Rate frames per second
Throughput Rate frames per second
TX Bit Rate Mb per second

How Results Are Calculated

Flood Count

When Spirent TestCenter sends traffic to an interface for forwarding, the destination MAC address of some of the frames may not match the MAC address of the interface. These frames are called flood frames.

The flood count is the total number of flood frames sent during the duration of a test iteration. It only includes frames sent from Spirent TestCenter, not frames sent by the DUT/SUT.

Intended Load

The configured load for an iteration.

RFC 2285: The rate of frames per second in which an external source attempts to send to a DUT/SUT for forwarding to specified output interfaces.

Offered Load

The actual load for an iteration.

The actual load can differ from the configured load because of duplex settings, flow control, link flapping, DIC (for 10G ports), and other factors.

The number of frames to be transmitted from one or more Spirent TestCenter ports to the DUT per second.

RFC 2285: The number of frames per second that an external source can be observed or measured to transmit to a DUT/SUT for forwarding to a specified output interface or interfaces.

TX Bit Rate

The bit rate (expressed in megabits per second) transmitted from one or more Spirent TestCenter ports to the DUT.

Tx Bit Rate (Mbps)=(Offered Load (fps) * FrameSize (bytes) * 8 ) / 1000000

Jitter

Frame Arrives
 		If (First in stream)
    Then
        Calculate delay(1)
    ElseIf (Out of Sequence) 
    Then
        Calculate delay(1)
    Else
        Calculate delay(2)
        Delay variation = delay(1) - delay(2)
        Update minimum and maximum jitter counters if required
        Add absolute value to jitter accumulator
        delay(1) = delay(2)
    EndIf

If the packet is the first received in the stream, then the packet transfer delay (latency) is calculated and stored. If a received packet is not the first packet in the stream then a check needs to be performed to make sure the packet is in the correct sequence. If the packet is not in sequence, latency results are discarded and this packet is treated as the new first packet in the stream. This stops measurement corruption caused by lost or out-of-sequence packets.

If the received packet is not the first packet and is in sequence, then the delay is calculated and stored. Next, the delay variation (jitter) is calculated by taking the difference of the delay of the current packet and the delay of the previous packet. Maximum, minimum, and accumulated jitter values are updated and stored. Finally, delay of the current packet is saved to be used as the previous packet delay when the next packet arrives.

The main advantages of the true real-time jitter measurement are no dependence on packets needing to be sent at a known interval; and, the method can measure jitter on variable rate (bursty) traffic. Also, this method does not restrict test duration. This is because the calculation occurs in real time as packets are received with no need of packet capture. Finally, this method compensates for lost and out-of-sequence packets while producing results in real-time for instant feedback even when varying traffic or device parameters.

Related Information

RFC Benchmark Test Overview