How to Use NTTTCP on Windows: Tests, Commands, and Tweaks

If you need to measure the real performance of your network on Windows (and also on Linux) without the storage or the CPU conditions youNTTTCP is one of the most reliable utilities for testing bandwidth and practical latency. This Microsoft tool focuses the load on the network layer and helps you detect bottlenecks, configuration issues, and physical link limits.

In this article we have gathered and reorganized into a single guide all the essentials for using NTTTCP.: requirements, installation on Windows and Linux, commands key, recommended test parameters (such as setting a common duration with -t), execution in Virtual machines and in Amazon EC2, TCP window tuning, reading results (MB/s, Mbps, cycles/byte, DPC, interrupts), and how to interpret retransmissions and errors. You'll also see when it makes sense to use iperf or other tools like ctsTraffic.

What is NTTTCP and why use it?

NTTTCP (NT Test TCP) is a free utility from Microsoft designed to measure network performance., both on physical and virtual machines, with a direct focus on the TCP/UDP stack. Its advantage is that it minimizes the influence of other subsystems (disks, back-end services, etc.) so that the test reflects the actual behavior of the link.

It is available for Windows, and there is a compatible implementation for Linux (ntttcp-for-linux), so you can perform homogeneous tests on different OSIt's especially useful in cloud environments like Azure or AWS, where the configuration of instances, network queues, and drivers has a significant impact.

NTTTCP allows you to control the number of threads, CPU mapping, ports and various timers, in addition to enabling specific modes for mixed testing between Windows and Linux. This allows you to simulate realistic loads, saturate multiple NIC queues, and observe the impact on interrupts, DPC, cycles/byte, and CPU utilization.

Requirements and environment example

First of all, make sure you have two computers or VMs with connectivity between them. (routes, security/network groups, firewall) and privileges to install/run tools. It's a good idea to have administrator permissions on Windows and sudo on Linux.

Example of parameters used throughout the text (you can adapt them):

Parameter	Price
Receiver IP	10.0.0.5
CPU cores per VM	2

On 1GbE networks, a sustained transfer rate around 112MB/s typically indicates that you are close to the theoretical maximum., provided the TCP stack is well-tuned and there are no losses. On 10 GbE or higher links, it will be essential to check the TCP window and, in some cases, consistently enable jumbo frames.

Installation and preparation on Windows and Linux

Windows: Download the latest version of NTTTCP from the official Microsoft repository (GitHub), unzip the package, and open a console with administrator privileges. Then, change to the directory that corresponds to your system architecture (for example, x64) to run the utility.

Linux: To use ntttcp-for-linux, first install the dependencies and compile it. On Ubuntu, you just need to build-essential y git; on SUSE, with git-core, gcc y make. Then clone and compile the project.

Preparation commands in Ubuntu (adjust them if your distro differs):

Runs on the Linux VM and check that there are no errors:
sudo apt-get update && sudo apt-get -y install build-essential git

Preparation Commands in SUSE (installs packages and resolves dependencies if they appear):
sudo zypper in -y git-core gcc make

Cloning and compiling ntttcp-for-linux (from any compatible distro):
git clone https://github.com/Microsoft/ntttcp-for-linux && cd ntttcp-for-linux/src && sudo make && sudo make install

How to run benchmarks with NTTTCP on Windows

The usual recommendation is to set a duration of 300 seconds (-t 300) on both transmitter and receiver. to stabilize throughput and monitor CPU and interrupt metrics over a significant period. Both sides should use the same -t value.

On the receiver (Windows), run replacing the number of cores and the destination IP with yours:
ntttcp -r -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Example receiver with 2 cores (4 wires) using the IP from the example:
ntttcp -r -m 4,*,10.0.0.5 -t 300

On the transmitter (Windows), the command is analogous but changing -r to -s to indicate that it sends:
ntttcp -s -m [num_de_nucleos x 2],*,10.0.0.5 -t 300

Example of a 4-wire transmitter pointing to the receiver 10.0.0.5:
ntttcp -s -m 4,*,10.0.0.5 -t 300

What to observe on the way out: Thread throughput, total MB/s, average frame size, buffers/s, cycles/byte, DPC, interrupts, packets sent/received, retransmissions, errors, and %CPU. These fields help you see if bandwidth is limited by the TCP stack, the NIC, or the CPU.

How to Run NTTTCP on Linux

In Linux, the syntax is practically identical.. Remember that if you don't specify -t, the default duration is usually 60 seconds, which may not be enough for a stable measurement.

Receiver (Linux) with 4 threads and 5 minutes duration:
ntttcp -r -m 4,*,10.0.0.5 -t 300

Transmitter (Linux) targeting the same receiver and same duration:
ntttcp -s -m 4,*,10.0.0.5 -t 300

Typical output on Linux summarizes connections created, duration, total bytes, throughput (Mbps), retransmissions (retrans segs), and CPU usage.Additionally, you'll see indicators like cycles/byte or the percentage of CPU usage, which are useful for understanding stack efficiency.

Mixed testing between Windows and Linux

To test between Windows and Linux, enable no-sync mode. To avoid internal handshaking issues: in Windows add -ns and in Linux it adds -NThis simplifies coordination between endpoints and prevents blockages due to implementation differences.

Relevant network settings: TCP/IP window size

On 1GbE, low-latency links, the default TCP window (~64KB with SO_RCVBUF in NTttcp) typically offers good performance.This avoids having to modify stack parameters for simple LAN cases.

On high latency networks or on 10GbE and above, the default window may fall short., reducing the effective throughput. Here, it is advisable to adjust the TCP window size to support a higher bandwidth x delay product.

NTTTCP allows you to statically pin the window with -rb, which disables stack autotuning. Only use this if you fully understand the implications, because forcing a large window in inappropriate scenarios can degrade performance.

As a general guideline, start with the default settings and scale up only if your case requires it. (high latency, WAN, multi-hop). Supplement these tests with the operating system's network tuning guides for persistent adjustments.

NTTTCP on Amazon EC2 (Windows) instances

If you operate on AWS, you can use NTTTCP to choose optimal instance types, sizes, and configurations.. The tests will help you compare actual performance against AWS's published performance for each EC2 family.

Recommended prerequisites for EC2 (Windows):

• Boot two Windows instances for network testing.
• Verify that they support Enhanced Networking (updated drivers and supported instance type).
• Adjust the MTU if they are not in the same Placement Group or do not use jumbo frames, maintaining end-to-end consistency.
• Check connectivity (RDP, ping if applicable, routes and security).

Installation in both instances: Download the latest version of NTttcp from Microsoft, unzip it into a folder and open it. CMD as Administrator. Enter the directory that corresponds to your instance's architecture before running.

Ports and security: By default, NTTTCP uses port 5001 for TCP and UDP, although you can change it with -p. Ensures that Security Groups and Windows Firewall allow traffic required and connections to ntttcp.exe (incoming and outgoing).

TCP Performance Test on EC2 (Receiver): initializes the listener from the chosen port. Example with two threads on ports 80–81, assigned to CPUs 0 and 1:
ntttcp -r -p 80 -a 6 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Meaning of the above parameters (receiver):

• -r: reception mode.
• -p 80: base port of the first thread (incremented by additional thread).
• and 6: Asynchronous I/O with 6 overlapping receive buffers per thread.
• -t 60: test duration in seconds.
• -cd 5: 5s cooldown to stabilize the end of the test.
• -wu 5: 5s warmup to stabilize the start.
• -v: detailed output.
• -xml c:\bench.xml: saves results in XML in the specified path (by default xml.txt).
• -m: Session mapping (threads, CPU ID, receiver IP), separating sessions by spaces.

TCP Performance Test on EC2 (Sender): Use the same parameters, switching to send mode and targeting the receiver's IP in both commands:
ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

Meaning of the specific parameters (issuer):

• -s: shipping mode.
• -p 80: base port per thread (increments per thread).
• -a: overlapped send buffers per thread (default 2, specify it if you want another value).
• -t, -cd, -wu: duration, cooldown and warmup, same as on the receiver.
• -m: Thread mapping, CPU and receiver IP, identical to the server side.

Output and metrics: On the receiver you can save an XML with a thread breakdown (real time, KB/s and MB/s, Mbps, bytes per completion, total bandwidth, buffers/s, interrupts per second, DPC/s, cycles/byte, packets sent/received, retransmissions, errors and %CPU). In a sample test with 2 threads, the aggregate can be in the range of several Gbps (e.g., ~9 Gbps) on suitable instances and well-tuned network.

UDP Performance Test on EC2: To validate the data plane without TCP congestion control, use the switch -u. Two-wire receiver on ports 80–81:
ntttcp -r -u -p 80 -t 60 -cd 5 -wu 5 -v -xml c:\bench.xml -m 1,0,192.168.1.4 1,1,192.168.1.4

Equivalent UDP transmitter, respecting IP and ports:
ntttcp -s -u -p 80 -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4

In UDP you will see MB/s, Mbps, average size per completion and buffers/s, along with interrupt counters and DPCs. Unlike TCP, there are no delivery guarantees, so errors and losses are more visible if you push the network to its limits.

Interpret results: throughput, retransmissions, and errors

Throughput (MB/s and Mbps): is the effective throughput. At 1 GbE, you can expect ~940 Mbps (about 112 MB/s) if everything is fine. At 10 GbE, levels close to 9–9.5 Gbps are reasonable without jumbo frames and better with optimal settings.

Buffers/s, average frame size and cycles/byte: These tell you how much load each thread is moving and the efficiency of the stack. High cycles/byte suggest the CPU is working too hard for each byte transferred.

DPC/interrupts per secondIf they spike, consider optimizing RSS/RSC/RDMA (if applicable), drivers, and CPU thread allocation. Poor allocation can create hot spots on a single core.

Broadcasts: Viewing some streams may be normal under load, but Sustained high numbers indicate losses or congestionWith a clean 1GbE, retransmissions should be low; if you see thousands in a few minutes, check the cabling, link quality, collisions (full duplex mis-negotiated), offloads (try disabling LSO/TSO for testing), NIC queues, and buffer pressure.

Errors: : the ideal is zero. If they appear, look for CRC on switches/NIC, inconsistent MTU, older drivers, or firewall/IDS rules that inspect excessively. Ensure jumbo frame consistency if you use them and that both endpoints support the same MTU.

Practical casesIf you're getting ~112 MB/s on a 1 GbE LAN but seeing ~3.000 retransmissions and ~400 errors in 5 minutes, this indicates intermittent loss. Try changing the cable/port, updating drivers, checking flow control, disabling temporary offloads, and repeat. If retransmissions drop dramatically, you've hit the target.

iperf vs NTTTCP and other useful tools

iperf is excellent for fast, cross-platform testing, and helps you demonstrate whether the network can sustain 1G/10G between two specific points. It's very useful for ruling out the network when the problem is with the application or storage.

NTTTCP offers more fine-grained control in Windows (thread and CPU mapping, asynchronous modes, detailed XML, DPC/interrupt metrics) and a Linux implementation that facilitates consistent testing. In Microsoft/Azure environments, it's often the benchmark.

ctsTraffic (Client to Server Traffic) is another Microsoft tool for generating and verifying traffic. It can complement NTTTCP if you want to profile more varied client-server patterns.

Methodology for 'putting out fires' between teamsRun tests from the affected hosts over the same network path. Repeat at different times, add controlled UDP tests, and collect captures on the NIC/switch. Only with high throughput in iperf/NTTTCP, low retransmissions, and zero errors can you demonstrate with data that the network is not the bottleneck.

Next steps and related information

Check MTU and end-to-end consistency (especially if you combine jumbo frames). On AWS, consider Placement Groups and Enhanced Networking. On Azure, align VM size with your throughput goals.

Experiment with the number of threads (-m) and CPU pinning to take advantage of RSS and multiple NIC queues. Set -ta to 300 s for stable testing and use -xml to retain results for comparison.

If you must mix Windows and Linux, remember -ns/-N. And if latency is significant, consider increasing the TCP window with -rb only to validate hypotheses, being careful with autotuning disabled.

A practical guide like this, which combines commands, interpretation and adjustments, will allow you to measure, understand and improve your network. without noise from other subsystems, making it clear whether the limit is in the infrastructure, the configuration, or the application design itself.