Dashboard – Performing Tests

To begin throughput testing, you need to launch both the client and server on different computers, as described in the previous chapter. In the client window, enter the hostname, IPv4 address, or IPv6 address of the server.

Additionally, if you changed the default port number on the server side, make sure to adjust the port number accordingly.

Click Connect, and the client will attempt to connect to the server. If the connection is successful, continuous throughput testing will commence and will continue until you click Disconnect.

The client window displays TCP and UDP upstream and downstream throughput values (both current and average), the loss percentage for UDP streams, and the round-trip time (RTT). The same data is illustrated by a dynamically updated chart.

The Protocols drop-down list offers three options for testing your network link: TCP and UDP, TCP Only, and UDP Only, which you can select depending on your testing requirements. You can also configure the QoS traffic type, which will be discussed in detail below.

The Chart panel contains several interface elements that control how the data is presented. The 3D switch toggles the 3D view on and off, the Metric drop-down list allows you to select which data subset to display: Throughput, UDP Packet Loss, RTT, or Jitter (alternatively, you can switch between the respective charts using the Ctrl + 1..4 keyboard shortcut). Finally, the Units drop-down list can be used to change the measurement units: gigabits per second, gigabytes per second, megabits per second, megabytes per second, kilobits per second, or kilobytes per second.

Please note a few important points:

• In the context of data rates, decimal prefixes are typically used with their standard SI interpretation. In other words, in this application, one megabit equals 1000² bits rather than 1024² bits.
• Jitter is measured according to the widely accepted method outlined in RFC 3550.
• If you select TCP Only as the testing protocol, the UDP-based metrics—UDP Packet Loss and Jitter—will not be available.

The Actions group of buttons offers quick chart actions: you can save the chart image, copy it to the clipboard, or clear the chart.

The status log window at the bottom displays messages about the current application’s status.

QoS Testing

Advanced users might want to use the QoS traffic type control to specify the Quality of Service traffic type associated with the TCP and UDP data streams sent and received by the application. A description of QoS and related standards and technologies, such as WMM, 802.11e, DSCP, and 802.11p, is beyond the scope of this manual. However, in brief, there are two reasons why you may want to use this functionality:

• To check how different QoS traffic types affect throughput. In a properly designed WLAN using enterprise-class APs, throughput values for high-priority traffic should exceed those for normal-priority traffic.
• To verify end-to-end QoS network design. In a properly designed LAN or WLAN, QoS-tagged traffic must traverse the entire network from the source to the destination through both wireless and wired segments, which may use different technologies and protocol implementations. When testing this scenario, you should use Tessabyte Throughput Test for generating QoS-tagged traffic, and then use packet capture and analysis tools to inspect the packets and verify the QoS or DSCP values in the captured packets.

The table below summarizes different QoS traffic types that you can use. Please note that not all the QoS types available in the application and described below have corresponding WMM access categories. In practice, this means that when you run Tessabyte Throughput Test on a WLAN client and select a QoS type with no WMM mapping, your Wi-Fi adapter driver might fail to QoS-tag packets altogether.