There’s something deeply satisfying about proving your network is actually fast instead of just hoping it is. That’s where iPerf3 comes in. Setting up a simple performance test from a Windows 10 laptop to a Ubuntu 26 server gives you a real-world way to validate throughput, latency behavior, packet loss, and overall network stability. Better yet, throwing a Windows 11 VM into the mix inside that Ubuntu host adds another layer of realism that mirrors modern production environments where virtualization is everywhere.
One of the best parts about using iPerf3 is how lightweight and brutally honest it is. There’s no fancy dashboard trying to sugarcoat poor performance. You run the server on Ubuntu, launch the client from the Windows 10 laptop, and suddenly you’ve got hard numbers staring back at you. Want to compare bare-metal networking versus virtualized networking inside the Windows 11 VM? Easy. Want to see how different NIC settings, MTU values, or virtual switch configurations affect throughput? iPerf3 turns those questions into measurable answers instead of guesswork and crossed fingers.
The real magic happens when you start documenting your testing methodology. It sounds boring until six months later when someone asks, “How did you get those numbers?” Writing down the exact commands, VM configuration, network topology, interface speeds, hypervisor settings, and test durations makes your results meaningful and repeatable. It also helps others replicate your work or improve your scripts instead of starting from scratch. A good lab document turns a one-time speed test into a reusable operational blueprint that your future self — and your coworkers — will absolutely appreciate.
Even better, scripting the tests opens the door to automation and long-term monitoring. Maybe today you’re manually launching iPerf3 sessions from your Windows 10 laptop, but tomorrow you could be running scheduled tests between the Ubuntu server and the Windows 11 VM every hour and logging the results automatically. That kind of consistency helps catch intermittent bottlenecks, virtualization overhead issues, or weird network gremlins before users start complaining that “the internet feels slow.” And honestly, finding problems before the help desk tickets arrive is basically the network engineer equivalent of achieving wizard status.
After you get your results you can search the internet for ways to improve performance. In cases you might get lucky, or you may find that is the best you can expect with the current equipment and configuration.
