Updates

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/microbenchmark-network-iperf3/basic-microbenchmarking.md

@@ -6,17 +6,17 @@ weight: 3
 layout: learningpathall
 ---
 
-## Microbenchmark the TCP connection
+With your systems configured and reachable, you can now use iPerf3 to microbenchmark TCP and UDP performance between your Arm-based systems
 
-You can microbenchmark the bandwidth between the client and server. 
+## Microbenchmark the TCP connection
 
-First, start `iperf` in server mode on the server system with the following command: 
+First, start by running `iperf` in server mode on the `SERVER` system with the following command: 
 
 ```bash
 iperf3 -s
 ```
 
-You see the output, indicating the server is ready:
+This starts the server on the default TCP port 5201. You should see:
 
 ```output
 -----------------------------------------------------------
@@ -28,17 +28,20 @@ Server listening on 5201 (test #1)
 The default server port is 5201. Use the `-p` flag to specify another port if it is in use.
 
 {{% notice Tip %}}
-If you already have an `iperf3` server running, you can manually kill the process with the following command. 
+If you already have an `iperf3` server running, you can kill the process with the following command: 
  ```bash
  sudo kill $(pgrep iperf3)
  ```
 {{% /notice %}}
 
-Next, on the client node, run the following command to run a simple 10-second microbenchmark using the TCP protocol. 
+## Run a TCP test from the client
+
+Next, on the client node, run the following command to run a simple 10-second microbenchmark using the TCP protocol: 
 
 ```bash
 iperf3 -c SERVER -V
 ```
+Replace `SERVER` with your server’s IP address or hostname. The -V flag enables verbose output. 
 
 The output is similar to:
 
@@ -68,18 +71,19 @@ rcv_tcp_congestion cubic
 
 iperf Done.
 ```
+## TCP result highlights
 
-- The`Cwnd` column prints the control window size and corresponds to the allowed number of TCP transactions in flight before receiving an acknowledgment `ACK` from the server. This adjusts dynamically to not overwhelm the receiver and adjust for variable link connection strengths. 
+- The`Cwnd` column prints the control window size and corresponds to the allowed number of TCP transactions in flight before receiving an acknowledgment `ACK` from the server. This value grows as the connection stabilizes and adapts to link quality.
 
-- The `CPU Utilization` row shows both the usage on the sender and receiver. If you are migrating your workload to a different platform, such as from x86 to Arm, there may be variations. 
+- The `CPU Utilization` row shows both the usage on the sender and receiver. If you are migrating your workload to a different platform, such as from x86 to Arm, this is a useful metric. 
 
-- The `snd_tcp_congestion cubic` abd `rcv_tcp_congestion cubic` variables show the congestion control algorithm used.
+- The `snd_tcp_congestion cubic` and `rcv_tcp_congestion cubic` variables show the congestion control algorithm used.
 
-- This `bitrate` shows the throughput achieved under this microbenchmark. As you can see, the 5 Gbps bandwidth available to the `t4g.xlarge` AWS instance is saturated. 
+- `Bitrate` shows the throughput achieved. In this example, the the `t4g.xlarge` AWS instance saturates its 5 Gbps bandwidth available. 
 
-![instance-network-size](./instance-network-size.png)
+![instance-network-size#center](./instance-network-size.png "Instance network size")
 
-### Microbenchmark UDP connection
+## UDP result highlights
 
 You can also microbenchmark the `UDP` protocol with the `-u` flag. As a reminder, UDP does not guarantee packet delivery with some packets being lost. As such you need to observe the statistics on the server side to see the percent of packets lost and the variation in packet arrival time (jitter). The UDP protocol is widely used in applications that need timely packet delivery, such as online gaming and video calls. 
 

content/learning-paths/servers-and-cloud-computing/microbenchmark-network-iperf3/setup.md

@@ -1,5 +1,5 @@
 ---
-title: Set up Arm-Based Linux systems for network performance testing with iPerf3
+title: Set up Arm-based Linux systems for network performance testing with iPerf3
 weight: 2
 
 ### FIXED, DO NOT MODIFY
@@ -19,16 +19,16 @@ The setup instructions below use AWS EC2 instances connected within a Virtual Pr
 
 To get started, create two Arm-based Linux instances, with each instance serving one role:
 
-* One acts as a server
-* One acts as a client
+* One acting as a server
+* One acting as a client
 
 The instructions below use two `t4g.xlarge` instances running Ubuntu 24.04 LTS. 
 
 ## Install software dependencies
 
 Use the commands below to install iPerf3, which is a powerful open-source CLI tool for measuring maximum achievable network bandwidth. 
 
-Install `iperf3` on both the client and server systems:
+Begin by installing iPerf3 on both the client and server systems:
 
 ```bash
 sudo apt update
@@ -43,7 +43,7 @@ If you're prompted to run `iperf3` as a daemon, answer "no".
 
 If you're working in a cloud environment like AWS, you must update the default security rules to enable specific inbound and outbound protocols. 
 
-From the AWS console:
+Using the AWS console, follow these instructions:
 
 * Navigate to the **Security** tab for each instance. 
 * Edit the **Inbound rules** to allow the following protocols:
@@ -77,7 +77,7 @@ ifconfig
 
 ### On the client
 
-Add the server's IP address and assign it with name `SERVER`:
+Add the server's IP address and assign it the name `SERVER`:
 
 ```output
 127.0.0.1       localhost
@@ -103,15 +103,15 @@ Add the client's IP address and assign it the name `CLIENT`:
 
 ## Confirm server is reachable
 
-Finally, confirm the client can reach the server with the ping command below. As a reference you can also ping the localhost. 
+Finally, confirm the client can reach the server by using the ping command below. As a reference, you can also ping the localhost. 
 
 ```bash
 ping SERVER -c 3 && ping 127.0.0.1 -c 3
 ```
 
 The output below shows that both SERVER and localhost (127.0.0.1) are reachable. 
 
-Localhost response times are typically ~10× faster than remote systems. Actual values will vary based on system location and network conditions.
+Localhost response times are typically ~10× faster than remote systems, though actual values will vary based on system location and network conditions.
 
 ```output
 PING SERVER (10.248.213.104) 56(84) bytes of data.
@@ -132,4 +132,4 @@ PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
 rtt min/avg/max/mdev = 0.022/0.027/0.032/0.004 ms
 ```
 
-Continue to the next section to learn how to measure the network bandwidth between the systems.
+Now that your systems are configured, you can move on to the next section to learn how to measure the network bandwidth between the systems.