How to Perform a Proper Network Load Test: LAN and Wi-Fi Stress Testing with Tessabyte

We hope you won't go that far...

Stress-testing a network is a bit like asking it, politely but firmly, to show you its true personality. Under light load, almost any LAN or Wi-Fi system looks perfectly fine. The switch blinks, the AP purrs, everyone’s calm, and nothing seems wrong. But once you apply enough load, networks begin revealing the traits they hide during normal operation: congestion, latency spikes, retransmissions, bufferbloat, interference, roaming delays, QoS misconfiguration, and all sorts of entertaining surprises.

If you’re an IT engineer, a field technician, or an MSP who needs to validate, benchmark, or troubleshoot a customer's LAN + Wi-Fi environment, you need a test that reflects real behavior under realistic load. That’s where proper network load testing comes in — not vague “internet speed tests,” but serious, controlled stress that exposes weak links on both the wired and wireless sides.

This brief guide explains (1) what you need to do to conduct a meaningful stress test, and (2) how to perform it using Tessabyte, a modern network testing tool designed specifically for generating realistic network load across many devices.

Part 1 — What You Need to Do Before Running a Network Stress Test

1.1 Define the Goal of the Test

A proper stress test answers real engineering questions:

• How much load can the LAN and Wi-Fi infrastructure handle before misbehaving?

• Do multiple users at peak hours push the network into instability?

• Is roaming smooth under load?

• Does the AP CPU become the bottleneck?

• Are QoS policies applied correctly?
  

A network running at 5% utilization always looks wonderful. You need to intentionally push it into 60–90% utilization to understand how it behaves under pressure.

1.2 Use Multiple Traffic Types

Networks don’t collapse because of average traffic — they collapse because of specific traffic patterns. Your test should combine:

• TCP (real-world downloads/uploads)

• UDP (pure packet-rate stress and jitter testing)

• Mixed traffic (TCP + UDP at the same time)

• Burst patterns (short TCP flows, frequent reconnects, and general connection churn)

This is exactly what Tessabyte makes easy: you can specify protocol mix, rates, QoS tags, and even enable stress mode to generate realistic connection churn.

1.3 Use Multiple Devices Across LAN and Wi-Fi

Real networks do not consist of one well-behaved laptop sitting next to the AP. Your load should reflect a typical office or SMB environment. Suggested mix:

• 1–2 wired desktops (gigabit or multi-gig)

• Several Wi-Fi laptops

• Older or low-end devices (to simulate low-capability clients)
  

This matters because Wi-Fi airtime is shared. A single weak 1x1 client transmitting at low MCS rates from the other end of the floor plan can dramatically reduce the throughput of everything else.

1.4 Test in Multiple Physical Locations

Wi-Fi is very sensitive to where you stand — and what stands between you and the AP. Recommended positions:

• Near line-of-sight

• One or two walls away

• End of hallway

• Meeting rooms

• Areas with glass, metal shelves, or other reflective surfaces
  

And if you have multiple APs, test while roaming, not just while standing still. Roaming under load is where many enterprise-class networks suddenly behave like consumer gear.

1.5 Don’t Forget the Wired Backhaul

Wi-Fi complaints often originate from the LAN infrastructure behind it. Check for:

• Switch ports stuck at half-duplex

• Damaged Ethernet cables

• Oversubscribed uplinks

• Small switches with tiny buffers

• VLAN misconfiguration

• Autonegotiation mismatches (especially with older gear)
  

In a proper network load test, both LAN and WLAN must be stressed — if the wired side collapses first, Wi-Fi performance becomes irrelevant.

1.6 Understand LAN vs Wi-Fi Bottlenecks

A quick summary:

LAN bottlenecks

• Limited switch backplane capacity

• Misconfigured speed/duplex

• Bufferbloat caused by cheap or unmanaged switches

• Traffic bursts overwhelming low-end hardware
  

Wireless bottlenecks

• Airtime limitations (the real currency of Wi-Fi)

• Retries due to interference or weak clients

• AP CPU constraints

• Rate-adaptation drops when devices move
  

Finally, a common LAN and Wi-Fi bottleneck is thermal throttling: overheating in switches or routers can cause them to get unstable, reboot, behave erratically, introduce latency, or temporarily drop packets to maintain thermal stability.

A good stress test measures how the whole system behaves together — not just isolated parts.

1.7 Add QoS / DSCP Considerations

This is a crucial topic that many network load testers ignore. QoS is supposed to prioritize important traffic (voice, conferencing, critical business apps). But if you generate huge volumes of traffic tagged with high DSCP values, you can unintentionally starve the rest of the network. In other words: Sending massive “priority traffic” can displace everything else.

Part of responsible network load testing is verifying that:

• High-priority DSCP flows do not wreck the network

• Low-priority flows are still delivered (albeit at reduced rates, depending on policy)

• Voice/video QoS behavior is correct under load

• The QoS policy matches the business intent
  

Tessabyte allows selecting QoS traffic type so you can precisely simulate how DSCP prioritization interacts with real network load.

1.8 What Good Results Look Like

You want:

• Stable throughput

• Predictable packet loss behavior

• Controlled jitter

• Moderate, not explosive, latency growth

• Continued usability of the network during load

• Smooth roaming, even if throughput drops
  

And remember: a stress test is not about achieving maximum Mbps — it’s about assessing network stability under strain.

Part 2 — How to Run a Network Load Test Using Tessabyte

Now that you know what makes a meaningful test, let’s walk through how to actually generate that load using Tessabyte.

2.1 Recommended Test Topology

Here is a simple starting setup for a mixed wired + Wi-Fi test, where Tessabyte Server is running on one of the wired computers, while other computers (connected over both wired and wireless links) are used to run Tessabyte Clients:

Simple network testing setup

Tessabyte Server can run on Windows, macOS, and Linux computers, while Tessabyte Client runs on Windows and macOS. For deeper stress testing, run two or more Tessabyte Servers on different wired segments.

You may also want to adjust the maximum number of client connections the server can accept, as shown below. This number can be greater than the actual number of clients (if you plan to test maximum load), or it can be smaller than the actual number of clients (if you plan to simulate frequent reconnect attempts to emulate connection churn).

Limiting client connections

If running Tessabyte Server on Linux, the maximum number of clients can be set using a command-line argument, as described in the help documentation.

2.2 Running Tessabyte Client

Tessabyte Client can run on Windows and macOS computers (iOS coming soon). On Windows and macOS you can run multiple instances in parallel, both manually and via command-line automation. This help chapter describes the syntax of Tessabyte client command-line parameters; they give you full control over protocols (TCP, UDP, or both), QoS values, rate limits, and stress mode.

Example

TessabyteClient.exe -c 192.168.12.9 -p 32500 -r u -q 1 -l 500 -s

This runs a UDP-only test at 500 Mbps using QoS class “Background”, reconnecting randomly to emulate churn.

To run multiple instances of Tessabyte client automatically, you can use simple scripting, as described below.

Windows .bat File:

@echo off
for /l %%i in (1,1,10) do (
   start "" "C:\Program Files\Tessabyte\TessabyteClient.exe" -c 192.168.12.9 -r tu -l 300
)

This launches 10 parallel clients, each generating TCP+UDP at 300 Mbps.

macOS .sh File:

#!/bin/bash
for i in {1..10}
do
    "/Applications/Tessabyte Client.app/Contents/MacOS/TessabyteClient" \
        -c 192.168.12.9 -r tu -l 300 &
done

This creates the same effect in macOS. Don’t forget to execute “chmod +x mytest.sh” to make your .sh file executable.

Running many instances from several devices simultaneously allows you to simulate real-world office traffic much more accurately than any single test tool could.

2.3 Test Scenarios Using Tessabyte

Generally, there are two base test scenario types (and an unlimited number of variations): overload tests and rate-limited tests. Overload tests are for failure mode, rate-limited tests are for quality under realistic usage.

The first basic type is a test where you try to fully saturate the network by sending/receiving the amount of data per second that exceeds the network capacity. In that scenario, you typically launch multiple clients on multiple wired and wireless devices and look for anomalies in your network and hardware behavior, such as high AP CPU usage, complete loss of connectivity for some devices due to thermal throttling, overheating network adapters, etc. Such tests should be conducted for an extended period of time, as these problems may not manifest themselves immediately.

The second basic type is a test where you try to imitate normal network load typical for your network by sending/receiving data with rate limiting:

Limiting data send rate

Once you’ve imitated a normal or high (but not excessive) LAN and WLAN network load using multiple computers running Tessabyte Client and Tessabyte Server, you can choose one of the devices running Tessabyte Client as your “observation point”. Again, look for anomalies in your network and hardware behavior, but unlike in the previous basic scenario type, focus on other anomalies, such as lower-than-expected throughput rates, high RTT, high jitter, high UDP loss, and slow Wi-Fi roaming.

Please remember that data streams generated by multiple running Tessabyte instances are not synchronized. This means that high variance in the charts is not always a sign of instability; it may be a sign of contending traffic if a specific link is shared by more than one client-server connection. For example, if you are running Tessabyte Server connected to a gigabit switch port and three Tessabyte Clients connected to three other ports that belong to the same switch, a single gigabit link between the switch and Tessabyte Server will be used to receive and send data from/to three clients, which means that throughput values for each individual clients will never reach the theoretical maximum (about 950 Mbit/s). Rather, they will fluctuate around 300-400 Mbit/s on the average (there are a few idle seconds in every testing cycle), as the testing cycles for these clients are not synchronized, and sometimes Tessabyte Server may be sending data to only one client, while at other times it may be sending data to three clients simultaneously.

One client connection: - flat and boring

Three client connections: a lot of fluctuations

That said, consider a few real-world ready-to-use scenarios below, and feel free to share yours in the comments!

Scenario A — Maximum Wi-Fi Throughput

• UDP and TCP load

• No rate limit

• Running a single Tessabyte Client instance on a Wi-Fi laptop near an AP

• Goal: measure AP’s real wireless capacity

  
  

Scenario B — Multi-Client Mixed Load

• 1–2 wired desktops

• 5–10 Wi-Fi laptops

• Mix of TCP and UDP

• Goal: observe airtime fairness, AP CPU behavior

  
  

Scenario C — QoS / DSCP Verification

Run two client groups:

1. Normal traffic QoS type (Best Effort)

2. High-priority traffic QoS type (Voice)
   

Verify that:

• High-priority flows gain precedence

• Low-priority flows are slowed, not dropped

• The network remains usable
  

Scenario D — Stress Mode Stability Test

Run multiple clients with the “-s” (stress test) command-line option. This simulates:

• Short-lived TCP connections

• Unpredictable load patterns

• Connection churn common in real offices
  

If the network collapses during this scenario, you’ve found a problem worth fixing.

2.4 Reading Tessabyte Results

Tessabyte provides clear metrics:

Throughput

Look for stability, not maximum peaks.

UDP Packet Loss

In the testing scenarios where you don’t limit the send rate, i.e. when you try to fully saturate the network, high UDP loss is totally acceptable. It’s similar to trying to inject 20 liters of water per second into a pipe the capacity of which is only 10 liters per second; you can read more about understanding UDP metrics. A different story are the testing scenarios where you do limit the send rate. For example, if you run five Tessabyte Client instances and limit them to 50 Mbps each, your network capacity is not exceeded, so a small loss under load is fine; explosive loss is not.

Jitter

A great indicator of Wi-Fi congestion or interference. Again, like in the case of UDP packet loss, high jitter values are acceptable in an overloaded, saturated network. Under normal load, jitter should be small. For your reference, recommended jitter limits for different applications are summarized below:

Application	Acceptable Jitter
VoIP	<30 ms (Ideal: <10 ms)
Video Conferencing (Zoom, Teams, etc.)	<40 ms
Online Gaming	<30 ms (Ideal: <10 ms)
Live Streaming (Twitch, YouTube Live, etc.)	<50 ms
Standard Video Streaming (Netflix, YouTube, etc.)	<100 ms

Round-trip Time a.k.a. Latency

Large spikes often indicate bufferbloat. In a healthy LAN, RTT is normally within a few milliseconds; it may be a few times higher in a Wi-Fi network due to airtime contention, power-save behavior, interference/retries, or roaming.

When running multi-client tests, compare results across devices to identify problem areas (e.g., one AP consistently underperforms, or one wired segment chokes first).

Conclusion

A proper network load test is the most reliable way to understand how a LAN and Wi-Fi system behaves under real-world pressure. Light traffic hides flaws; heavy traffic reveals them. By combining multiple devices, mixed protocols, varying locations, and realistic connection patterns, you get a true picture of network stability.

Tessabyte makes this process practical and repeatable. You can run many clients in parallel, generate TCP/UDP load, apply QoS tags, script automated load patterns, and observe behavior under controlled stress.

If you're deploying networks professionally — or supporting customers as an MSP — proper network stress and load testing isn’t optional. It’s part of responsible engineering.

Download Tessabyte and start testing your networks the way professionals do — under real load.