The Global Statistics panel show all ports and streams currently in your testbed. It does not show any other ports (or streams on these ports), not even if they have been reserved by you.
The panel is divided into two tabs. The first tab show testbed-global Port Statistics and the other show testbed-global Stream Statistics.
Common Toolbar Functions
The two statistics tabs share a common toolbar with the following functions:
|Function ||Explanation |
|Start Traffic ||Start traffic on all ports in your testbed. Ports that are already transmitting are not affected. This command may also affect any capture and histograms defined for the ports if you have enabled it. |
|Stop Traffic ||Stop traffic on all ports in your testbed. Ports that are not transmitting are not affected. This command may also affect any capture and histograms defined for the ports if you have enabled it. |
|Running Time ||Show the amount of time that has elapsed since you performed a Start Traffic command in this panel. If an individual port had been started before this point in time this is not reflected in the Running Time value. |
|Stop At ||Allow you to specify a time limit for the port transmission. When the Running Time exceeds this value the port traffic will be automatically stopped. |
|Force Port Limit ||If checked: Use “TX Time Limit” to enforce “Stop At” value. |
|Errors ||Display the total number of errors on all ports in your testbed. |
|Clear Counters ||Clear the current statistics counters for all streams on all ports. |
|Mark ||Set the font color of the current counter values to gray. Any counter value that changes afterward will revert to blue. This makes it easy to check if a value changes over time. |
|Save ||Allow you to save the current counters to a CSV text file. |
|TX Stream Display ||Can be used to reduce the number of streams that are displayed in the Stream Statistics page. The options are: |
- All defined (all streams are shown)
- Only with non-zero counters
- Only transmitting
|Clean RX Filters ||Clean out any inactive filters |
Common Column Header Functions
The two statistics tabs also share a common functionality w.r.t. the grid column headers. You can reorder the columns in the grid by dragging a column header to a new location. The new order will be remembered the next time you start ValkyrieManager. The following options are available when right-clicking on the grid column headers:
|Function ||Explanation |
|Hide Column: ||Hide the selected column from view. This selection will be remembered the next time you start ValkyrieManager. |
|Reset Column Order: ||Resets any custom column order you may have configured to the default order. |
|View All Columns: ||Show all columns you may have hidden previously. |
The Port Statistics tab show statistics counters for all ports in your testbed. In general each port is represented by a single row which contains both Tx and Rx counters for that port.
The Port Summary section provides a brief overview of the main port state properties for the testbed ports.
Traffic Statistics Counters
The available statistics counters for each port are the same as for the individual port statistics page described here.
The Stream Statistics tab show statistics counters for all streams on all ports in your testbed. Each counter type is explained in the individual port statistics page described here.
The counters are shown in a gridview where each row represent both ends of a stream. The stream “ends” are matched together using the Test Payload ID (TID) which is configured on the stream at the transmit end and transferred to the received end within the Xena test payload inside each packet. To enable an accurate matching of Tx and Rx stream ends it is imperative that the used TID values are unique within the testbed. Otherwise it will be impossible to determine which stream on which port was the sender of a given packet.
Aggregated Stream Statistics
This section show the aggregated counter values for all streams in the view.
Stream Traffic Statistics
This section show the main stream traffic counters for each stream.
Each row in the grid represents a test-stream end-to-end. The stream entity is identified by the TID value. The Tx counter values are read from the transmitting port and the Rx counter values are read from the receiving port.
If two or more streams in your testbed use the same TID value the Stream Statistics grid will not be able to accurately determine where the various TID contributions originate from on the receiving side. The grid will show this situation as a single parent row representing all receive-side contributions from the given TID value. The Dest.Port will be shown as Multiple for the parent row (see example below). The transmit-side contributions will be shown in the parent row. The receive-side contributions will be listed in child rows, one for each port receiving packets with the TID value. You can expand the child rows by clicking the expander icon to the left of the row. The aggregated receive-side contributions are listed in the parent row.
The Stream Errors section show the errors detected for each end-to-end stream entity. The mechanism for showing TID conflicts explained above is also used here. The following error counters are shown:
|(TX-RX) ||The difference between the sent packets for the stream on the transmitting port and the received packets on the matching TID entry on the receiving port. This value is not accurate while the traffic is running as it is not possible to accurately read TX and RX counters on different ports at exactly the same time. So this value is only shown when traffic is stopped. |
|Lost Packets ||The calculated loss based on the embedded sequence number in the test payload section in the received packets. This value is somewhat accurate while the traffic is running. It is especially good at detecting on-going loss. But it cannot detect lost packets at the very start or at the very end of the packet stream since the receiver cannot know how many packets were sent before the first packet it receives or how many packets are actually lost after the last packet it receives. |
|Misordered ||The number of misordered packets detected, i.e. packets arriving out of sequence compared to the embedded sequence number in the test payload section. The same uncertainty regarding packets at the very start or at the very end explained above applies here as well. |
|Payload Errors ||The number of packets received that failed the test payload integrity check. These packets are not counted as lost or misordered as they strictly speaking are valid Ethernet packets. But their presence indicates that the DUT/SUT changed something in the payload section which caused the payload integrity check to fail. |
|Bit Error Rate ||This value is an estimated bit error rate (BER) measured over the timespan since the traffic counters were last cleared. The BER value provided is estimated based on the assumption that 1 errored packet equals 1 bit error. If more than one bit error occurred in one errored packet this will not be detected by the Xena tester. Based on this assumption the estimated BER is calculated as follows by the ValkyrieManager: BER = LostPackets / ((8.0 * rxBytes)+LostPackets) |
|Packet Loss Ratio ||Packet Loss Ratio = LostPackets / TX(Packets) |
Latency and Jitter
The Latency and Jitter section shows the latency and jitter values calculated for each end-to-end stream entity. The mechanism for showing TID conflicts explained above is also used here. Please observe that jitter is calculated for TID values 0-31