Dealing with Common Problems

Sharing Bandwidth with Other Clients

As the Tessabyte Throughput Test server can handle multiple clients concurrently, when more than one client is connected to the server, the bandwidth is inevitably shared among them. Unless the server has a very wide bandwidth connection that far exceeds the clients' bandwidth, you should expect that multiple concurrent client connections will affect the per-client throughput.

For example, consider a local LAN segment with a 1 Gbps link between a server and a few client computers. If you run a Tessabyte client on just one of these client computers, you can expect a maximum throughput of about 0.9 Gbps. If three clients are connected, there will inevitably be time periods when all three are sending a TCP stream to the server, as the testing cycles (TCP Up → TCP Down → UDP Up → UDP Down) are not synchronized. During such times, throughput might drop to approximately 0.3 Gbps per client. However, when only one client is sending data at the given moment, throughput may reach 0.9 Gbps. To summarize, the chart may appear volatile when multiple client connections are active.

Note that the client's log window on the Dashboard page keeps you informed about the number of currently connected clients whenever this number changes. This way, you can always determine whether the connection is exclusively yours or if other clients are sharing the bandwidth with you.

Low TCP Throughput

If you observe consistently low throughput compared to what you expect from the network link between the server and the client, then first of all—congratulations! You've used the right tool to discover the problem. However, after a brief celebration, let's dig into the issue. The most common reasons for a throughput below the expected level are:

• Wi-Fi networks: If you are measuring throughput over a Wi-Fi network, it's important to remember that the maximum PHY rate advertised by the wireless AP or router is only a theoretical maximum and is never reached in practice. In real-life scenarios, many constraints limit Wi-Fi throughput, such as:
  • Client capabilities: For example, only 2 MIMO streams versus 4 MIMO streams supported by the AP, or a 160 MHz channel width versus 320 MHz supported by the AP.
  • Protocol overhead: The overhead caused by protocol headers.
  • Signal strength: Weak signals reduce throughput.
  • RF noise: Radio frequency interference can degrade performance.
  • Medium contention: When multiple clients are connected, they compete for the shared wireless medium, further reducing throughput.
• Competing traffic (congestion): Network traffic competes for available bandwidth, which can lead to congestion. This issue is particularly significant in Wi-Fi networks, where multiple clients share a small number of radio channels and employ collision avoidance mechanisms to manage access. By contrast, modern wired networks—such as those using gigabit switches—are designed with sufficient internal capacity to handle the combined bandwidth of all ports simultaneously. For example, a 4-port gigabit switch can theoretically support up to 4 Gbps of aggregate traffic (1 Gbps per port, in both directions). That said, while traffic congestion is less common on wired local segments, it can still occur in certain scenarios.
• CPU or system bottlenecks: High CPU usage or poor NIC offloading performance limits throughput. Modern NICs support offloading tasks (e.g., checksum, segmentation), and missing these optimizations leads to CPU overload.
• Intermediate network devices: Routers, firewalls, or proxy servers in the path can throttle or delay traffic. Misconfigurations, traffic shaping, or policy-based throttling can restrict throughput.
• Faulty cabling: Damaged cables can cause signal degradation, resulting in packet loss and frequent retransmissions. Poorly shielded cables or cables not meeting category specifications (e.g., Cat5e, Cat6) may suffer from electromagnetic interference or crosstalk. Finally, modern Ethernet devices use auto-negotiation to determine the best possible link speed (e.g., 1 Gbps, 100 Mbps), so faulty cabling or poor-quality cables may cause the link to fall back to a lower speed, such as 100 Mbps instead of 1 Gbps.
• Thermal throttling: If a network card overheats, it may throttle and reduce its processing speed. This can cause lower throughput and packet loss, especially at high data rates. Overheating in switches or routers can also cause them to throttle their packet-processing speed, introduce latency, or temporarily drop packets to maintain thermal stability.

Note that this is by no means a comprehensive list; there are many other potential causes of low throughput, such as high network latency and small TCP window size, packet fragmentation, etc.

Abnormally High TCP Throughput

Sometimes, the reported throughput rate might exceed the theoretical maximum. For example, while testing a 5 Gbps link between two computers, you might observe a spike in TCP downlink or uplink throughput that exceeds 5 Gbps. This is typically caused by buffering at the operating system level, where a relatively large chunk of data is accumulated before being "pushed" to the receiving application.

If you observe such spikes, the best solution is to use a custom TCP payload size. The payload size should be large enough to take at least half a second to transfer over your network link. To learn how to use a custom TCP payload size, refer to the Customizing Settings chapter.

Network Connection Down After a Few Testing Cycles

This might not be a good sign for your network infrastructure. Any throughput testing tool generates a considerable load on the network hardware, sometimes to the extent that the hardware fails to reliably handle the high load. While the specific reason may vary (for example, the adapter chips might overheat, triggering a self-protection mechanism such as thermal shutdown), this is often an indication that the infrastructure being tested is unable to pass the stress test.

High Uplink and/or Downlink UDP Loss

Generally, non-zero loss of UDP packets is totally normal. Unlike TCP, the UDP protocol is connectionless and does not guarantee delivery. Several factors may contribute to such loss:

• Network congestion: Network devices (routers, switches) have limited buffer space. When the network is overloaded, packets are dropped.
• Packet rate exceeds hardware capacity: If the sending node transmits packets faster than the receiving node or intermediary hardware (e.g., routers) can process, packets will be dropped.
• Buffer overflows: Both sending and receiving nodes have network buffers. If these buffers overflow due to a high packet arrival rate, packets are dropped.
• Misconfigured network parameters: A Maximum Transmission Unit (MTU) mismatch can cause packets larger than the MTU to be fragmented or dropped. Ensure you are not using a custom UDP packet size that exceeds the MTU (configured on the Customizing Settings page). Some hardware may drop fragmented UDP packets. For example, if your custom packet size is 2,000 bytes, your UDP packets will likely be fragmented.
• QoS settings: UDP traffic may be deprioritized in favor of other protocols, such as TCP or UDP with a higher QoS tag. Use the QoS control to check how a high-priority QoS tag affects performance.
• Slow/old computer:: Try running Tessabyte on a different computer. Your current computer may be old, slow, or its CPU might be loaded by other processes.

High Downlink UDP Loss in WLANs

High downstream UDP loss is quite common when running the client on computer with a Wi-Fi link. UDP traffic is not acknowledged, meaning the sender can transmit as much traffic as the network can handle without “caring” about how much of it is lost. If you run the server on the wired side of the network, a typical computer equipped with a gigabit adapter can send hundreds of megabits per second. This data will first reach a switch, which might be the first bottleneck, and then the access point, which is also often a bottleneck. In a multi-client environment, even modern 802.11be APs cannot provide a gigabit downlink to all clients simultaneously. As a result, many UDP packets might be lost en route. However, this is the only way to determine the maximum downstream UDP throughput.

100% Downlink UDP Loss

A 100% downlink UDP loss is typically caused by a firewall or NAT issue. This means that the UDP data sent from the server cannot reach the client. During UDP testing, the client sends upstream UDP traffic to the server from an arbitrary UDP port to the server port (32500 by default). The return downstream traffic originates from an arbitrary server port and is sent to a port on the client side, determined by the following rule: (server port, 32500 by default) + 1. If this port is unavailable, the next available port is selected. While this information can help you configure a firewall or port forwarding rule, UDP traffic cannot easily traverse NATs. If you want to test UDP, you should avoid using NATs or consider using IPv6, which generally eliminates the need for NAT.