I need to measure network bandwidth between Amazon EC2 Windows instances. How can I do that?

Several factors can affect Amazon EC2 network performance, including:

  • Physical proximity of EC2 instances, listed in descending order:
    • Instances in the same Availability Zone
    • Instances in different Availability Zones of the same region
    • Instances in different regions on the same continent
    • Instances in different regions on different continents
  • EC2 instance maximum transmission unit (MTU). The default interface configuration for EC2 instances uses jumbo frames (9001 MTU), which allows greater throughput in a single virtual private cloud (VPC). However, outside a single VPC, the maximum MTU is 1500 or less, requiring large packets to be fragmented by intermediate systems. Therefore, the default MTU value of 9001 may be inefficient, costing more in processing overhead than it saves in network throughput, especially when most of your network traffic is Internet facing. The instance types that can be configured to use jumbo frames include CC2, C3, R3, CG1, CR1, G2, HS1, I2, T2, and M3. For more information see Instance Types.
  • EC2 instance size. Larger instance sizes for an instance type typically provide better network performance than smaller instance sizes of the same type.
  • EC2 enhanced networking support for Windows, with the exception of T2 and M3 instance types.
  • EC2 high performance computing (HPC) support using placement groups. HPC provides full-bisection bandwidth and low latency, with support for 10 gigabit network speeds. For more information, see Launching Instances into a Placement Group. See the Instance Types Matrix to review network performance for each instance type.

Because of these factors, there is often a significant network performance difference between cloud environments. Best practices for evaluating the impact of network performance on cloud-based applications should include periodic baseline network benchmark testing of your environment. This article describes the steps required to set up, configure, and benchmark network performance between EC2 Windows instances. Because network performance is often a critical aspect of application performance, testing network performance can provide valuable insight for determining the EC2 instance types, sizes, and configuration that best suits your needs.

Before beginning benchmark tests, launch and configure your Windows EC2 instances:

  1. Follow the steps in Launch a Windows Instance to launch two Windows instances from which you can run network performance testing.
  2. For the best possible network performance, ensure that the instances support enhanced networking for Windows, launch the instances in the same VPC, and follow the steps in Enabling Enhanced Networking on Windows Instances in a VPC.
  3. If you are performing network testing between instances that are not co-located in the same placement group or do not support jumbo frames, follow the steps in Network Maximum Transmission Unit (MTU) for Your EC2 Instance to Check and Set the MTU on your Amazon EC2 Instance.
  4. Complete the steps in Connect to Your Windows Instance Using RDP to verify that you can access the instances.

Connect to your Windows instances via RDP and do the following:

  1. Download NTttcp-v5.31.zip from the Microsoft TechNet NTttcp download page.
  2. Unzip the contents of the file to a folder.
  3. Open a command prompt with Administrator privileges and change directories to the folder where you unzipped NTttcp-v5.31.zip.
  4. Change directories to the folder with the name matching the architecture of your EC2 Windows instance before running NTttcp.

NTttcp communicates over port 5001 by default when testing TCP performance; however, this port is configurable using the -p switch. Ensure that security groups are configured to allow communication over the ports that will be used by NTttcp. Also add inbound and outbound Windows Firewall rules on both the receiver and sender that allow NTttcp.exe connections.

  1. Configure one instance as a receiver/server to initialize listeners starting with the default port of 5001, or specify an alternate initial listener port with the -p switch. For example, the following command initializes a two-threaded receiver that listens on ports 80–81 of the specified IP address, with the first thread running on CPU 0 and the second thread running on CPU 1. All ntttcp.exe receiver parameters used in this example are described below the command:
         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
         • -r — receive
         • -p 80 — port used by first thread to receive data; the port number is incremented for each additional receiver thread
         • -a 6 — asynchronous data transfer that posts 6 receive overlapped buffers per thread
         • -t 60 — test duration in seconds
         • -cd 5 — test cooldown time of 5 seconds
         • -wu 5 — test warmup time of 5 seconds
         • -v — specify verbose test output
         • -xml — save test output to specified file (default saves to xml.txt)
         • -m — specify 3 mapping parameters per session (# threads, CPUID, receiver IP address); multiple sessions are space delimited
  2. Configure a second instance as a sender/client and run a test against the receiver with the desired parameters. For example, the following command initializes a two-threaded TCP sender to ports 80-81 of the specified IP address, with the first thread running on CPU 0 and the second thread running on CPU 1. All ntttcp.exe sender parameters used in this example are described below the command:
         ntttcp -s -p 80 -a -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4
         • -s — send
         • -p 80 — port used by first thread to send data; this port number is incremented for each additional sending thread
         • -a — use default value of 2 asynchronous send overlapped buffers per thread; specify non-default value if desired
         • -t 60 — test duration in seconds
         • -cd 5 — test cooldown time of 5 seconds
         • -wu 5 — test warmup time of 5 seconds
         • -m — specify 3 mapping parameters per session (# threads, CPUID, destination IP address); multiple sessions are space delimited

The xml output generated on the receiver should resemble the following. In this test, the total bandwidth utilized was about 9.02 Gbits/sec.

bandwidth-tcp

NTttcp communicates over port 5001 by default when testing UDP performance; however, this port is configurable using the -p switch. Ensure that security groups are configured to allow communication over the ports that will be used by NTttcp. Also add inbound and outbound Windows Firewall rules on both the receiver and sender that allow NTttcp.exe connections.

  1. Configure one instance as a receiver/server to initialize listeners starting with the default port of 5001, or specify an alternate initial listener port with the -p switch. For example, the following command initializes a two-thread receiver listening on ports 80¬–81 of the specified IP address, with the first thread running on CPU 0 and the second thread running on CPU 1. All ntttcp.exe receiver parameters used in this example are described below the command:
         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
         • -r — receive
         • -u — test UDP
         • -p 80 — port used by first thread to receive data; the port number is incremented for each additional receiver thread
         • -t 60 — test duration in seconds
         • -cd 5 — test cooldown time of 5 seconds
         • -wu 5 — test warmup time of 5 seconds
         • -v — specify verbose test output
         • -xml — save test output to specified file (default saves to xml.txt)
         • -m — specify 3 mapping parameters per session (# threads, CPUID, receiver IP address); multiple sessions are space delimited
  2. Configure a second instance as a sender/client and run a test against the receiver with the desired parameters. For example, the following command initializes a two-threaded UDP sender to ports 80–81 of the specified IP address, with the first thread running on CPU 0 and the second thread running on CPU 1. All ntttcp.exe sender parameters used in this example are described below the command:
         ntttcp -s –u -p 80 -t 60 -cd 5 -wu 5 -m 1,0,192.168.1.4 1,1,192.168.1.4
         • -s — send
         • -u — test UDP (default is to test TCP)
         • -p 80 — port used by first thread to send data; this port number is incremented for each additional sending thread
         • -t 60 — test duration in seconds
         • -cd 5 — test cooldown time of 5 seconds
         • -wu 5 — test warmup time of 5 seconds
         • -m — specify 3 mapping parameters per session (# threads, CPUID, destination IP address); multiple sessions are space delimited

The xml output generated on the receiver should resemble the following.

bandwidth-udp

To quickly view all of the switches available for use with NTttcp, run ntttcp from a command prompt.

For more information about the options available for use with NTttcp, see the TCP_Tool.docx Word file that is included with the NTttcp download file and review the latest updates to NTttcp on the Microsoft TechNet NTttcp download page.

Amazon EC2 Windows, network, performance, placement groups, HPC, throughput, NTttcp, MTU, VPC, UDP, TCP


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center.