edits

v-thepet · v-thepet · commit 226819af327c · 2023-03-23T22:24:02.000-07:00
diff --git a/articles/virtual-network/virtual-network-bandwidth-testing.md b/articles/virtual-network/virtual-network-bandwidth-testing.md
@@ -1,5 +1,5 @@
 ---
-title: Test Azure VM network throughput by using NTTTCP
+title: Test 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
@@ -10,71 +10,67 @@ ms.date: 03/23/2023
 ms.author: allensu
 ---
 
-# Test network bandwidth or throughput with NTTTCP
+# Test VM network throughput by using NTTTCP
 
-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.
+This article describes how to use the free NTTTCP tool from Microsoft to test network bandwidth and throughput performance on Azure Windows or Linux virtual machines (VMs). A tool like NTTTCP targets the network for testing and minimizes the use of other resources that could affect performance.
 
 ## Prerequisites
 
-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.
+To test throughput, you need two VMs of the same size to function as *sender* and *receiver*. The two VMs should be in the same [proximity placement group](/azure/virtual-machines/co-location) or [availability set](/azure/virtual-machines/availability-set-overview), so you can use their internal IP addresses and exclude load balancers from the test.
 
-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.
+Note the number of cores and the IP addresses for the VMs to use in the following procedures. Both the sender and receiver commands use the receiver's IP address.
 
 >[!NOTE]
 >Testing by using a virtual IP (VIP) is possible, but is beyond the scope of this article.
 
-## Test throughput for Windows or Linux VMs
+## Test throughput between Windows VMs or Linux VMs
 
-You can test throughput on Windows or Linux machines.
-
-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. 
+You can test throughput from Windows VMs by using [NTTTCP](https://github.com/microsoft/ntttcp) or from Linux VMs by using [NTTTCP-for-Linux](https://github.com/Microsoft/ntttcp-for-linux).
 
 # [Windows](#tab/windows)
 
 ### Set up NTTTPS and test configuration
 
 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*.
 
-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\\*.
+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. Run the following command, replacing `c:\tools` with the path you downloaded *ntttcp.exe* to if different.
 
    ```cmd
-   netsh advfirewall firewall add rule program=<path>ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY
+   netsh advfirewall firewall add rule program=c:\tools\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY
    ```
 
-   For example, if you copied *ntttcp.exe* to *c:\\tools*, run the following command: 
-
-   `netsh advfirewall firewall add rule program=c:\tools\ntttcp.exe name="ntttcp" protocol=any dir=in action=allow enable=yes profile=ANY`
-
 1. To confirm your configuration, test a single Transfer Control Protocol (TCP) stream for 10 seconds by running the following commands:
 
    - 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`.
 
-   >[!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.
-
    >[!NOTE]
    >Use the preceding commands only to test configuration.
 
+   >[!TIP]
+   >When you run the test for the first time to verify setup, use a short test period to get quick feedback. Once you verify the tool is working, extend the test period to 300 seconds for the most accurate results.
+
 ### Run NTTTCP tests
 
-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.
+Run *ntttcp.exe* from the Windows command line, not from PowerShell. Run the 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 you don't specify a time parameter.
+
+1. On the receiver VM, run the following command, replacing the `<number of VM cores>`, and `<receiver IP address>` placeholders with your own values.
 
    ```cmd
-   ntttcp -r -m [<number of VM cores> * 2],*,<receiver IP address> -t 300
+   ntttcp -r -m [<number of VM cores> x 2],*,<receiver IP address> -t 300
    ```
 
-   The command for a VM with four cores and an IP address of `10.0.0.4` looks like the following example:
+   The following example shows an NTTTCP command for a VM with four cores and an IP address of `10.0.0.4`.
 
    `ntttcp -r -m 8,*,10.0.0.4 -t 300`
 
-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.
+1. On the sender VM, run the following command. The sender and receiver commands differ only in the `-s` or `-r` parameter that designates the sender or receiver VM.
 
    ```cmd
-   ntttcp -s -m [<number of VM cores> * 2],*,<receiver IP address> -t 300
+   ntttcp -s -m [<number of VM cores> x 2],*,<receiver IP address> -t 300
    ```
 
-   The following example shows the command if the receiver IP address is `10.0.0.4`:
+   The following example shows the sender command for a receiver IP address of `10.0.0.4`.
    
    ```cmd
    ntttcp -s -m 8,*,10.0.0.4 -t 300 
@@ -88,29 +84,29 @@ Run the NTTTCP test for 300 seconds, or five minutes, on both the sender and rec
 
 To measure throughput from Linux machines, use [NTTTCP-for-Linux](https://github.com/Microsoft/ntttcp-for-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:
+1. Prepare both the sender and receiver VMs for NTTTCP-for-Linux by running the following commands, depending on your distro:
 
-   - For **CentOS**, install `gcc` and `git`:
+   - For **CentOS**, install `gcc` and `git`.
 
      ``` bash
      yum install gcc -y  
      yum install git -y
      ```
 
-   - For **Ubuntu**, install `build-essential` and `git`:
+   - For **Ubuntu**, install `build-essential` and `git`.
 
      ``` bash
      apt-get -y install build-essential  
      apt-get -y install git
      ```
 
-   - For **SUSE**, install `git-core`, `gcc`, and `make`:
+   - For **SUSE**, install `git-core`, `gcc`, and `make`.
 
      ``` bash
      zypper in -y git-core gcc make
      ```
 
-1. Make and install NTTTCP-for-Linux:
+1. Make and install NTTTCP-for-Linux.
 
    ``` bash
    git clone https://github.com/Microsoft/ntttcp-for-linux
@@ -122,52 +118,51 @@ To measure throughput from Linux machines, use [NTTTCP-for-Linux](https://github
 
 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.
 
-1. On the receiver VM, start NTTTCP-for-Linux and run the test for 300 seconds.
+1. On the receiver VM, run NTTTCP-for-Linux for 300 seconds.
 
    ``` bash
    ntttcp -r -t 300
    ```
 
-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:
+1. On the sender VM, run NTTTCP-for-Linux for 300 seconds. The following example shows a command for a receiver VM with an IP address of `10.0.0.4`.
 
    ``` bash
    ntttcp -s10.0.0.4 -t 300
    ```
 
-## Test throughput between Windows and Linux VMs
+---
+## Test throughput between a Windows VM and a Linux VM
 
-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.
+To run NTTTCP throughput tests between a Windows VM and a Linux VM, enable no-sync mode by using the `-ns` flag on Windows or the `-N` flag on Linux.
 
 1. Install and configure NTTTCP on the Windows VM and NTTTCP-for-Linux on the Linux VM as instructed in the previous section.
 
-1. Test throughput on both the Windows and the Linux machines, as follows:
-
-   From the Windows VM:
+1. Test throughput from the Windows or Linux VMs as follows:
 
-   - Test with the Windows VM as the receiver:
+   - On the Windows VM, to test with the Windows VM as the receiver, run the following command:
 
      ```cmd
-     ntttcp -r -m [<number of VM cores> * 2],*,<Linux VM IP>
+     ntttcp -r -m [<number of VM cores> x 2],*,<Linux VM IP address>
      ```
-   - Test with the Windows VM as the sender:
+   - On the Windows VM, to test with the Windows VM as the sender, run the following command:
 
      ```cmd
-     ntttcp -s -m [<number of VM cores> * 2],*,<Linux VM IP> -ns -t 300
+     ntttcp -s -m [<number of VM cores> x 2],*,<Linux VM IP address> -ns
      ```
 
-   From the Linux VM:
-   
-   - Test with the Linux VM as the receiver:
+   - On the Linux VM, to test with the Linux VM as the receiver, run the following command:
 
      ```bash
-     ntttcp -r -m [<number of VM cores> * 2],*,<Windows VM IP>
+     ntttcp -r -m [<number of VM cores> x 2],*,<Windows VM IP address>
      ```
 
-   - Test with the Linux VM as the sender:
+   - On the Linux VM, to test with the Linux VM as the sender, run the following command:
 
      ```bash
-     ntttcp -s -m [<number of VM cores> * 2],*,<Windows VM IP> -N -t 300
-```
+     ntttcp -s -m [<number of VM cores> x 2],*,<Windows VM IP address> -N
+     ```
+
+---
 
 ## Test Cloud Service instances
 
diff --git a/articles/virtual-network/virtual-network-test-latency.md b/articles/virtual-network/virtual-network-test-latency.md
@@ -15,11 +15,11 @@ ms.author: allensu
 
 This article describes how to test network latency between Azure virtual machines (VMs) by using the publicly available tools [Latte](https://github.com/microsoft/latte) for Windows or [SockPerf](https://github.com/mellanox/sockperf) for Linux.
 
-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.
+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 this traffic has the largest effect on application performance.
 
 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.
 
-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.
+Latte and SockPerf measure only TCP or UDP payload delivery times. These tools don't measure ICMP and other packet types that applications don't use and that don't affect application performance.
 
 Latte and SockPerf use the following approach to measure network latency between two physical or virtual computers:
 
@@ -39,13 +39,13 @@ Use the following best practices to test and analyze network latency:
 
 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 effects of any of the following changes on network latency:
+1. Test the effects on network latency of changing any of the following components:
    - 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.
    - Virtual network configuration, such as routing or filtering changes.
 
-1. Always compare new test results to the baseline or to the lasest test results before the controlled changes.
+1. Always compare new test results to the baseline or to the latest test results before controlled changes.
 
 1. Repeat tests whenever you observe or deploy changes.
 
@@ -67,7 +67,9 @@ Use the following procedures to install and test network latency with [Latte](ht
 
 ### Test latency between VMs
 
-1. On the receiver VM, start *latte.exe* from the Windows command line, not from PowerShell. Run the following command, replacing the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
+Run *latte.exe* from the Windows command line, not from PowerShell.
+
+1. On the receiver VM, run the following command, replacing the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
 
    ```cmd
    latte -a <receiver IP address>:<port> -i <iterations>
@@ -78,7 +80,7 @@ Use the following procedures to install and test network latency with [Latte](ht
 
    For a VM with an IP address of `10.0.0.4`, the command might look like:<br><br>`latte -a 10.0.0.4:5005 -i 65100`
 
-1. On the *sender* VM, start *latte.exe* from the command line. Run the same command as on the receiver, except with `-c` added to indicate the *client* or sender VM. Again replace the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
+1. On the *sender* VM, run the same command as on the receiver, except with `-c` added to indicate the *client* or sender VM. Again replace the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
 
    ```cmd
    latte -c -a <receiver IP address>:<port> -i <iterations>
@@ -96,32 +98,32 @@ Use the following procedures to install and test network latency with [Latte](ht
 
 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) or CentOS
-
-```bash
-#RHEL/CentOS - Install Git and other helpful tools
-    sudo yum install gcc -y -q
-    sudo yum install git -y -q
-    sudo yum install gcc-c++ -y
-    sudo yum install ncurses-devel -y
-    sudo yum install -y automake
-    sudo yum install -y autoconf
-    sudo yum install -y libtool
-```
-
-#### Ubuntu
-
-```bash
-#Ubuntu - Install Git and other helpful tools
-    sudo apt-get install build-essential -y
-    sudo apt-get install git -y -q
-    sudo apt-get install -y autotools-dev
-    sudo apt-get install -y automake
-    sudo apt-get install -y autoconf
-    sudo apt-get install -y libtool
-    sudo apt update
-    sudo apt upgrade
-```
+- Red Hat Enterprise Linux (RHEL) or CentOS:
+
+  ```bash
+  #RHEL/CentOS - Install Git and other helpful tools
+      sudo yum install gcc -y -q
+      sudo yum install git -y -q
+      sudo yum install gcc-c++ -y
+      sudo yum install ncurses-devel -y
+      sudo yum install -y automake
+      sudo yum install -y autoconf
+      sudo yum install -y libtool
+  ```
+
+- Ubuntu:
+
+  ```bash
+  #Ubuntu - Install Git and other helpful tools
+      sudo apt-get install build-essential -y
+      sudo apt-get install git -y -q
+      sudo apt-get install -y autotools-dev
+      sudo apt-get install -y automake
+      sudo apt-get install -y autoconf
+      sudo apt-get install -y libtool
+      sudo apt update
+      sudo apt upgrade
+  ```
 
 ### Copy, compile, and install SockPerf
 
@@ -152,17 +154,17 @@ sudo make install
    sudo sockperf sr --tcp -i 10.0.0.4 -p 12345
    ```
 
-1. Now that the server is listening, on the *sender* or client computer, start sending packets to the server on the listening port, in this case `12345`.
-
-   - The `-t` option sets testing time in seconds. About 100 seconds is long enough to return representative results.
-   - The `-m` denotes message size in bytes. A 350-byte message size is typical for an average packet. You can adjust the size higher or lower to more accurately represent your VM's workloads.
+1. Now that the receiver is listening, run the following command on the *sender* or client computer to send packets to the receiver on the listening port, in this case `12345`.
 
    ```bash
    #Client/Sender for IP 10.0.0.4:
    sockperf ping-pong -i 10.0.0.4 --tcp -m 350 -t 101 -p 12345 --full-rtt
    ```
 
-1. Wait for the results. Depending on how far apart the VMs are, the number of iterations varies. To test for success before you run longer tests, consider starting with shorter tests of about 5 seconds.
+   - The `-t` option sets testing time in seconds. About 100 seconds is long enough to return representative results.
+   - The `-m` denotes message size in bytes. A 350-byte message size is typical for an average packet. You can adjust the size to more accurately represent your VM's workloads.
+
+1. Wait for the results. Depending on how far apart the VMs are, the number of iterations varies. To test for success before you run longer tests, consider starting with shorter tests of about five seconds.
 
 ---
 
