add throughput article

Author: v-thepet

articles/virtual-network/virtual-network-bandwidth-testing.md

@@ -1,174 +1,187 @@
 ---
-title: Testing Azure VM network throughput
-titlesuffix: Azure Virtual Network
-description: Use NTTTCP to target the network for testing and minimize the use of other resources that could impact performance.
+title: Test Azure VM network throughput by using NTTTCP
+description: Use the NTTTCP tool to test network bandwidth and throughput performance for Windows and Linux VMs on a virtual network.
 services: virtual-network
 author: asudbring
 ms.service: virtual-network
 ms.topic: how-to
 ms.workload: infrastructure-services
-ms.date: 10/06/2020
+ms.date: 03/23/2023
 ms.author: allensu
 ---
 
-# Bandwidth/Throughput testing (NTTTCP)
+# Test network bandwidth or throughput with NTTTCP
 
-When testing network throughput performance in Azure, it's best to use a tool that targets the network for testing and minimizes the use of other resources that could impact performance. NTTTCP is recommended.
+This article describes how to use the free NTTTCP tool from Microsoft to test network throughput performance on Azure Windows or Linux virtual machines (VMs). To test network throughput and bandwidth, it's best to use a tool like NTTTCP that targets the network for testing and minimizes the use of other resources that could affect performance.
 
-Copy the tool to two Azure VMs of the same size. One VM functions as SENDER
-and the other as RECEIVER.
+## Prerequisites
 
-#### Deploying VMs for testing
-For the purposes of this test, the two VMs should be in either the same [Proximity Placement Group](../virtual-machines/co-location.md) or the same Availability Set so that we can use their internal IPs and exclude the Load Balancers from the test. It is possible to test with the VIP but this kind of testing is outside the scope of this document.
+To test throughput, you need two VMs of the same size to function as *sender* and *receiver*. The two VMs should be in either the same [proximity placement proup](/azure/virtual-machines/co-location) or the same [availability set](/azure/virtual-machines/availability-set-overview), so you can use their internal IP addresses and exclude load balancers from the test.
 
-Make a note of the RECEIVER's IP address. Let's call that IP "a.b.c.r"
+Note the number of VM cores and the VM IP addresses to use in the following procedures. Both the sender and receiver commands use the receiver's IP address.
 
-Make a note of the number of cores on the VM. Let's call this "\#num\_cores"
+>[!NOTE]
+>Testing by using a virtual IP (VIP) is possible, but is beyond the scope of this article.
 
-Run the NTTTCP test for 300 seconds (or 5 minutes) on the sender VM and receiver VM.
+## Test throughput for Windows or Linux VMs
 
-Tip: When setting up this test for the first time, you might try a shorter test period to get feedback sooner. Once the tool is working as expected, extend the test period to 300 seconds for the most accurate results.
+You can test throughput on Windows or Linux machines.
 
-> [!NOTE]
-> The sender **and** receiver must specify **the same** test duration
-parameter (-t).
->
-> The IP address in both Sender and Receiver commands is the Receiver's IP address.
-> 
-> The -r and -s flags are no longer required for the receiver and sender parameters.
+Run the NTTTCP test for 300 seconds, or five minutes, on both the sender and receiver VMs. The sender and receiver must specify the same test duration for the `-t` parameter. Test duration defaults to 60 seconds if no time parameter is specified. 
 
-To test a single TCP stream for 10 seconds:
+# [Windows](#tab/windows)
 
-Receiver parameters: ntttcp -r -t 10 -P 1
+### Set up NTTTPS and test configuration
 
-Sender parameters: ntttcp -s10.27.33.7 -t 10 -n 1 -P 1
+1. On both the sender and receiver VMs, [download the latest version of NTTTCP](https://github.com/microsoft/ntttcp/releases/latest) into a separate folder like *c:\\tools*.
 
-> [!NOTE]
-> The preceding sample should only be used to confirm your configuration. Valid examples of testing are covered later in this document.
+1. On the receiver VM, create a Windows Defender Firewall `allow` rule to allow the NTTTCP traffic to arrive. It's easier to allow *nttcp.exe* by name than to allow specific inbound TCP ports. In the following command, replace the `<path>` placeholder with the path you downloaded *ntttcp.exe* to, such as *c:\\tools\\*.
 
-## Testing VMs running WINDOWS:
+   ```cmd
+   netsh advfirewall firewall add rule program=<path>ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY
+   ```
 
-#### Get NTTTCP onto the VMs.
+   For example, if you copied *ntttcp.exe* to *c:\\tools*, run the following command: 
 
-Download the latest version:
-https://github.com/microsoft/ntttcp/releases/latest
+   `netsh advfirewall firewall add rule program=c:\tools\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY`
 
-Consider putting NTTTCP in separate folder, like c:\\tools
+1. To confirm your configuration, test a single Transfer Control Protocol (TCP) stream for 10 seconds by running the following commands:
 
-#### Allow NTTTCP through the Windows firewall
-On the RECEIVER, create an Allow rule on the Windows Firewall to allow the
-NTTTCP traffic to arrive. It's easiest to allow the entire NTTTCP program by
-name rather than to allow specific TCP ports inbound.
+   - On the receiver VM, run `ntttcp -r -t 10 -P 1`.
+   - On the sender VM, run `ntttcp -s<receiver IP address> -t 10 -n 1 -P 1`.
 
-Allow ntttcp through the Windows Firewall like this:
+   >[!TIP]
+   >When you run the test for the first time to verify setup, you use a short test period. Once you verify the tool is working, extend the test period to 300 seconds for the most accurate results.
 
-netsh advfirewall firewall add rule program=\<PATH\>\\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY
+   >[!NOTE]
+   >Use the preceding commands only to test configuration.
 
-For example, if you copied ntttcp.exe to the "c:\\tools" folder, this would be the command: 
+### Run NTTTCP tests
 
-netsh advfirewall firewall add rule program=c:\\tools\\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY
+1. On the receiver VM, start *ntttcp.exe* from the Windows command line, not from PowerShell. Run the following command, replacing the `<number of VM cores>`, and `<receiver IP address>` placeholders with your own values.
 
-#### Running NTTTCP tests
+   ```cmd
+   ntttcp -r -m [<number of VM cores> * 2],*,<receiver IP address> -t 300
+   ```
 
-Start NTTTCP on the RECEIVER (**run from CMD**, not from PowerShell):
+   The command for a VM with four cores and an IP address of `10.0.0.4` looks like the following example:
 
-ntttcp -r -m [2\*\#num\_cores],\*,a.b.c.r -t 300
+   `ntttcp -r -m 8,*,10.0.0.4 -t 300`
 
-If the VM has four cores and an IP address of 10.0.0.4, it would look like this:
+1. On the sender VM, run the following command from a Windows command line. The sender and receiver commands differ only in the `-s` or `-r` parameter that designates the sender or receiver VM.
 
-ntttcp -r -m 8,\*,10.0.0.4 -t 300
+   ```cmd
+   ntttcp -s -m [<number of VM cores> * 2],*,<receiver IP address> -t 300
+   ```
 
+   The following example shows the command if the receiver IP address is `10.0.0.4`:
+   
+   ```cmd
+   ntttcp -s -m 8,*,10.0.0.4 -t 300 
+   ```
 
-Start NTTTCP on the SENDER (**run from CMD**, not from PowerShell):
+1. Wait for the results.
 
-ntttcp -s -m 8,\*,10.0.0.4 -t 300 
+# [Linux](#tab/linux)
 
-Wait for the results.
+### Prepare VMs and install NTTTPS-for-Linux
 
+To measure throughput from Linux machines, use [NTTTCP-for-Linux](https://github.com/Microsoft/ntttcp-for-linux).
 
-## Testing VMs running LINUX:
+1. On both the sender and receiver VMs, run the following commands to prepare NTTTCP-for-Linux on your VMs, depending on your distro:
 
-Use nttcp-for-linux. It is available from <https://github.com/Microsoft/ntttcp-for-linux>
+   - For **CentOS**, install `gcc` and `git`:
 
-On the Linux VMs (both SENDER and RECEIVER), run these commands to prepare ntttcp-for-linux on your VMs:
+     ``` bash
+     yum install gcc -y  
+     yum install git -y
+     ```
 
-CentOS - Install gcc and git:
-``` bash
-  yum install gcc -y  
-  yum install git -y
-```
-Ubuntu - Install build-essential and git:
-``` bash
- apt-get -y install build-essential  
- apt-get -y install git
-```
-SUSE - Install git-core, gcc, and make:
-``` bash
-  zypper in -y git-core gcc make
-```
-Make and Install on both:
-``` bash
- git clone https://github.com/Microsoft/ntttcp-for-linux
- cd ntttcp-for-linux/src
- make && make install
-```
+   - For **Ubuntu**, install `build-essential` and `git`:
 
-As in the Windows example, we assume the Linux RECEIVER's IP is 10.0.0.4
+     ``` bash
+     apt-get -y install build-essential  
+     apt-get -y install git
+     ```
 
-Start NTTTCP-for-Linux on the RECEIVER:
+   - For **SUSE**, install `git-core`, `gcc`, and `make`:
 
-``` bash
-ntttcp -r -t 300
-```
+     ``` bash
+     zypper in -y git-core gcc make
+     ```
 
-And on the SENDER, run:
+1. Make and install NTTTCP-for-Linux:
 
-``` bash
-ntttcp -s10.0.0.4 -t 300
-```
- 
-Test length defaults to 60 seconds if no time parameter is given
+   ``` bash
+   git clone https://github.com/Microsoft/ntttcp-for-linux
+   cd ntttcp-for-linux/src
+   make && make install
+   ```
 
-## Testing between VMs running Windows and LINUX:
+### Run NTTTCP tests
 
-On this scenarios we should enable the no-sync mode so the test can run. This is done by using the **-N flag** for Linux, and **-ns flag** for Windows.
+Run the NTTTCP test for 300 seconds, or five minutes, on both the sender VM and the receiver VM. The sender and receiver must specify the same test duration for the `-t` parameter. Test duration defaults to 60 seconds if you don't specify a time parameter.
 
-#### From Linux to Windows:
+1. On the receiver VM, start NTTTCP-for-Linux and run the test for 300 seconds.
 
-Receiver \<Windows>:
+   ``` bash
+   ntttcp -r -t 300
+   ```
 
-``` bash
-ntttcp -r -m <2 x nr cores>,*,<Windows server IP>
-```
+1. On the sender VM, run NTTTCP-for-Linux for 300 seconds. The command for a receiver VM with an IP address of `10.0.0.4` looks like the following example:
 
-Sender \<Linux> :
+   ``` bash
+   ntttcp -s10.0.0.4 -t 300
+   ```
 
-``` bash
-ntttcp -s -m <2 x nr cores>,*,<Windows server IP> -N -t 300
-```
+## Test throughput between Windows and Linux VMs
 
-#### From Windows to Linux:
+To run NTTTCP throughput tests between a Windows and a Linux VM, enable no-sync mode by using the `-ns` flag on Windows or the `-N` flag on Linux.
 
-Receiver \<Linux>:
+1. Install and configure NTTTCP on the Windows VM and NTTTCP-for-Linux on the Linux VM as instructed in the previous section.
 
-``` bash
-ntttcp -r -m <2 x nr cores>,*,<Linux server IP>
-```
+1. Test throughput on both the Windows and the Linux machines, as follows:
+
+   From the Windows VM:
 
-Sender \<Windows>:
+   - Test with the Windows VM as the receiver:
 
-``` bash
-ntttcp -s -m <2 x nr cores>,*,<Linux  server IP> -ns -t 300
+     ```cmd
+     ntttcp -r -m [<number of VM cores> * 2],*,<Linux VM IP>
+     ```
+   - Test with the Windows VM as the sender:
+
+     ```cmd
+     ntttcp -s -m [<number of VM cores> * 2],*,<Linux VM IP> -ns -t 300
+     ```
+
+   From the Linux VM:
+   
+   - Test with the Linux VM as the receiver:
+
+     ```bash
+     ntttcp -r -m [<number of VM cores> * 2],*,<Windows VM IP>
+     ```
+
+   - Test with the Linux VM as the sender:
+
+     ```bash
+     ntttcp -s -m [<number of VM cores> * 2],*,<Windows VM IP> -N -t 300
 ```
-## Testing Cloud Service Instances:
-You need to add following section into your ServiceDefinition.csdef
+
+## Test Cloud Service instances
+
+Add the following section to *ServiceDefinition.csdef*:
+
 ```xml
 <Endpoints>
   <InternalEndpoint name="Endpoint3" protocol="any" />
 </Endpoints> 
 ```
 
 ## Next steps
-* Depending on results, there may be room to [Optimize network throughput machines](virtual-network-optimize-network-bandwidth.md) for your scenario.
-* Read about how [bandwidth is allocated to virtual machines](virtual-machine-network-throughput.md)
-* Learn more with [Azure Virtual Network frequently asked questions (FAQ)](virtual-networks-faq.md)
+
+- [Optimize network throughput for Azure virtual machines](virtual-network-optimize-network-bandwidth.md).
+- [Virtual machine network bandwidth](virtual-machine-network-throughput.md).
+- [Test VM network latency](virtual-network-test-latency.md)
+- [Azure Virtual Network frequently asked questions (FAQ)](virtual-networks-faq.md)

articles/virtual-network/virtual-network-test-latency.md

@@ -17,39 +17,35 @@ This article describes how to test network latency between Azure virtual machine
 
 For the most accurate results, you should measure VM network latency with a tool that's designed for the task and excludes other types of latency, such as application latency. Latte and SockPerf provide the most relevant network latency results by focusing on Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) traffic. Most applications use these protocols, and they have the greatest effect on application performance.
 
-Many other common network latency test tools, such as Ping, don't measure the type of network traffic that's used in real workloads. These tools use Internet Control Message Protocol (ICMP), which most applications don't use, and which can be treated differently from application traffic. These test results might not apply to workloads that use TCP and UDP.
+Many other common network latency test tools, such as Ping, don't measure TCP or UDP traffic. Tools like Ping use Internet Control Message Protocol (ICMP), which can be treated differently from application traffic. ICMP test results don't directly apply to workloads that use TCP and UDP.
 
-Tools like Latte or SockPerf measure only TCP or UDP payload delivery times. These tools don't measure ICMP or other packet types that aren't used by applications and don't affect application performance.
+Latte and SockPerf measure only TCP or UDP payload delivery times. These tools don't measure ICMP or other packet types that applications don't use and that don't affect application performance.
 
-## Network latency test process
-
-Latte or SockPerf use the following approach to measure network latency between two physical or virtual computers:
+Latte and SockPerf use the following approach to measure network latency between two physical or virtual computers:
 
 1. Create a two-way communications channel between the computers by designating one as sender and one as receiver.
 1. Send and receive packets in both directions and measure the round-trip time (RTT).
 
-## VM configuration for optimum latency
+## Tips and best practices for optimizing network latency
 
-To optimize VMs for network latency, observe the following recommendations when you create your VMs:
+To optimize VMs for network latency, observe the following recommendations when you create the VMs:
 
 - Use the latest version of Windows or Linux.
 - Enable [Accelerated Networking](accelerated-networking-overview.md) for increased performance.
 - Deploy VMs within an [Azure proximity placement group](/azure/virtual-machines/co-location).
 - Create larger VMs for better performance.
 
-### Latency testing best practices
-
-Use the following process to test network latency and analyze results:
+Use the following best practices to test and analyze network latency:
 
-1. As soon as you complete VM deployment, configuration, and optimizations, take baseline measurements to establish a benchmark for network latency between deployed VMs.
+1. As soon as you finish deploying, configuring, and optimizing network VMs, take baseline network latency measurements between deployed VMs to establish benchmarks.
 
-1. Test the effect on network latency of any changes to:
+1. Test the effects of any of the following changes on network latency:
    - Operating system (OS) or network stack software, including configuration changes.
    - VM deployment method, such as deploying to an availability zone or proximity placement group (PPG).
    - VM properties, such as Accelerated Networking or size changes.
-   - The virtual network, such as routing or filtering changes.
+   - Virtual network configuration, such as routing or filtering changes.
 
-1. Always compare new test results to the baseline or to the last test results before controlled changes.
+1. Always compare new test results to the baseline or to the lasest test results before the controlled changes.
 
 1. Repeat tests whenever you observe or deploy changes.
 
@@ -63,7 +59,7 @@ Use the following procedures to install and test network latency with [Latte](ht
 
 1. [Download the latest version of latte.exe](https://github.com/microsoft/latte/releases/download/v0/latte.exe) to both VMs, into a separate folder such as *c:\\tools*.
 
-1. On the *receiver* VM, create a Windows Defender Firewall `allow` rule to allow the Latte traffic to arrive through Windows Defender Firewall. It's easiest to allow the *latte.exe* program by name rather than to allow specific inbound TCP ports. In the command, replace the `<path>` placeholder with the path you downloaded *latte.exe* to, such as *c:\\tools\\*.
+1. On the *receiver* VM, create a Windows Defender Firewall `allow` rule to allow the Latte traffic to arrive. It's easier to allow the *latte.exe* program by name than to allow specific inbound TCP ports. In the command, replace the `<path>` placeholder with the path you downloaded *latte.exe* to, such as *c:\\tools\\*.
 
    ```cmd
    netsh advfirewall firewall add rule program=<path>latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY
@@ -98,9 +94,9 @@ Use the following procedures to install and test network latency with [Latte](ht
 
 ### Prepare VMs
 
-On both the *sender* and *receiver* Linux VMs, run the following commands to prepare SockPerf on the VMs, depending on your Linux distro.
+On both the *sender* and *receiver* Linux VMs, run the following commands to prepare SockPerf, depending on your Linux distro.
 
-# [Red Hat Enterprise Linux (RHEL) / CentOS](#tab/linux/rhel)
+#### Red Hat Enterprise Linux (RHEL) or CentOS
 
 ```bash
 #RHEL/CentOS - Install Git and other helpful tools
@@ -113,7 +109,7 @@ On both the *sender* and *receiver* Linux VMs, run the following commands to pre
     sudo yum install -y libtool
 ```
 
-# [Ubuntu](#tab/linux/ubuntu)
+#### Ubuntu
 
 ```bash
 #Ubuntu - Install Git and other helpful tools
@@ -127,11 +123,9 @@ On both the *sender* and *receiver* Linux VMs, run the following commands to pre
     sudo apt upgrade
 ```
 
----
-
 ### Copy, compile, and install SockPerf
 
-Copy, compile, and install SockPerf according to the following steps:
+Copy, compile, and install SockPerf by running the following commands:
 
 ```bash
 #Bash - all distros
@@ -151,7 +145,7 @@ sudo make install
 
 ### Run SockPerf on the VMs
 
-1. After the SockPerf installation is complete, start SockPerf on the *receiver* VM. Any available port number is fine. The following example uses port `12345`. Replace the example IP address `10.0.0.4` with your own value.
+1. After the SockPerf installation is complete, start SockPerf on the *receiver* VM. Any available port number is fine. The following example uses port `12345`. Replace the example IP address `10.0.0.4` with the IP address of your receiver VM.
 
    ```bash
    #Server/Receiver for IP 10.0.0.4: