You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/microbenchmark-network-iperf3/_index.md
+8-11Lines changed: 8 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,20 +1,17 @@
1
1
---
2
-
title: Get started with network microbenchmarking and tuning with iperf3
3
-
4
-
draft: true
5
-
cascade:
6
-
draft: true
2
+
title: Microbenchmark and tune network performance with iPerf3 and Linux traffic control
7
3
8
4
minutes_to_complete: 30
9
5
10
-
who_is_this_for: This is an introductory topic for performance engineers, Linux system administrators, or application developers who want to microbenchmark, simulate, or tune the networking performance of distributed systems.
6
+
who_is_this_for: This is an introductory topic for performance engineers, Linux system administrators, and application developers who want to microbenchmark, simulate, or tune the networking performance of distributed systems.
11
7
12
8
learning_objectives:
13
-
- Understand how to use iperf3 and tc for network performance testing and traffic control to microbenchmark different network conditions.
14
-
- Identify and apply basic runtime parameters to tune application performance.
9
+
- Run accurate network microbenchmark tests using iPerf3.
10
+
- Simulate real-world network conditions using Linux Traffic Control (tc).
11
+
- Tune basic Linux kernel parameters to improve network performance.
15
12
16
13
prerequisites:
17
-
- Foundational understanding of networking principles such as TCP/IP and UDP.
14
+
- Basic understanding of networking principles such as Transmission Control Protocol/Internet Protocol (TCP/IP) and User Datagram Protocol (UDP).
18
15
- Access to two [Arm-based cloud instances](https://learn.arm.com/learning-paths/servers-and-cloud-computing/csp/).
19
16
20
17
author: Kieran Hejmadi
@@ -25,13 +22,13 @@ subjects: Performance and Architecture
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/microbenchmark-network-iperf3/basic-microbenchmarking.md
+46-20Lines changed: 46 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,17 +6,19 @@ weight: 3
6
6
layout: learningpathall
7
7
---
8
8
9
-
## Microbenchmark the TCP connection
9
+
With your systems configured and reachable, you can now use iPerf3 to microbenchmark TCP and UDP performance between your Arm-based systems.
10
10
11
-
You can microbenchmark the bandwidth between the client and server.
11
+
## Microbenchmark the TCP connection
12
12
13
-
First, start `iperf` in server mode on the server system with the following command:
13
+
Start by running `iperf` in server mode on the `SERVER` system:
14
14
15
15
```bash
16
16
iperf3 -s
17
17
```
18
18
19
-
You see the output, indicating the server is ready:
19
+
This starts the server on the default TCP port 5201.
@@ -25,20 +27,23 @@ Server listening on 5201 (test #1)
25
27
26
28
```
27
29
28
-
The default server port is 5201. Use the `-p` flag to specify another port if it is in use.
30
+
The default server port is 5201. If it is already in use, use the `-p` flag to specify another.
29
31
30
32
{{% notice Tip %}}
31
-
If you already have an `iperf3` server running, you can manually kill the process with the following command.
33
+
If you already have an `iperf3` server running, terminate it with:
32
34
```bash
33
35
sudo kill$(pgrep iperf3)
34
36
```
35
37
{{% /notice %}}
36
38
37
-
Next, on the client node, run the following command to run a simple 10-second microbenchmark using the TCP protocol.
39
+
## Run a TCP test from the client
40
+
41
+
On the client node, run the following command to run a simple 10-second microbenchmark using the TCP protocol:
38
42
39
43
```bash
40
-
iperf3 -c SERVER -V
44
+
iperf3 -c SERVER -v
41
45
```
46
+
Replace `SERVER` with your server’s hostname or private IP address. The `-v` flag enables verbose output.
42
47
43
48
The output is similar to:
44
49
@@ -68,28 +73,47 @@ rcv_tcp_congestion cubic
68
73
69
74
iperf Done.
70
75
```
76
+
## TCP result highlights
77
+
78
+
- 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.
79
+
80
+
- 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.
81
+
82
+
- The `snd_tcp_congestion cubic` and `rcv_tcp_congestion cubic` variables show the congestion control algorithm used.
83
+
84
+
-`Bitrate` shows the throughput achieved. In this example, the the `t4g.xlarge` AWS instance saturates its 5 Gbps bandwidth available.
71
85
72
-
- 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 `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.
88
+
## UDP result highlights
75
89
76
-
- The `snd_tcp_congestion cubic` abd `rcv_tcp_congestion cubic` variables show the congestion control algorithm used.
90
+
You can also microbenchmark the `UDP` protocol using the `-u` flag with iPerf3. Unlike TCP, UDP does not guarantee packet delivery which means some packets might be lost in transit.
77
91
78
-
- 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.
92
+
To evaluate UDP performance, focus on the server-side statistics, particularly:
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.
98
+
These metrics help assess reliability and responsiveness under real-time conditions.
85
99
86
-
Run the following command from the client to send 2 parallel UDP streams with the `-P 2` option.
100
+
UDP is commonly used in latency-sensitive applications such as:
101
+
102
+
* Online gaming
103
+
104
+
* Voice over IP (VoIP)
105
+
106
+
* Video conferencing and streaming
107
+
108
+
Because it avoids the overhead of retransmission and ordering, UDP is ideal for scenarios where timely delivery matters more than perfect accuracy.
109
+
110
+
Run the following command from the client to send two parallel UDP streams with the `-P 2` option:
87
111
88
112
```bash
89
-
iperf3 -c SERVER -V -u -P 2
113
+
iperf3 -c SERVER -v -u -P 2
90
114
```
91
115
92
-
Looking at the server output you observe 0% of packets where lost for the short test.
116
+
Look at the server output and you can see that none (0%) of packets were lost for the short test:
93
117
94
118
```output
95
119
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
@@ -98,8 +122,10 @@ Looking at the server output you observe 0% of packets where lost for the short
title: Set up Arm-based Linux systems for network performance testing with iPerf3
3
3
weight: 2
4
4
5
5
### FIXED, DO NOT MODIFY
6
6
layout: learningpathall
7
7
---
8
8
9
-
## Configure two Arm-based Linux computers
9
+
## Environment setup and Learning Path focus
10
10
11
-
To perform network performance testing you need two Linux computers. You can use AWS EC2 instances with Graviton processors or any other Linux virtual machines from another cloud service provider.
11
+
To benchmark bandwidth and latency between Arm-based systems, you'll need to configure two Linux machines running on Arm.
12
12
13
-
You will also experiment with a local computer and a cloud instance to learn the networking performance differences compared to two cloud instances.
13
+
You can use AWS EC2 instances with Graviton processors, or Linux virtual machines from any other cloud service provider.
14
14
15
-
The instructions below use EC2 instances from AWS connected in a virtual private cloud (VPC).
15
+
This tutorial walks you through a local-to-cloud test to compare performance between:
16
16
17
-
To get started, create two Arm-based Linux instances, one system to act as the server and the other to act as the client. The instructions below use two `t4g.xlarge` instances running Ubuntu 24.04 LTS.
17
+
* Two cloud-based instances
18
+
* One local system and one cloud instance
18
19
19
-
### Install software dependencies
20
+
The setup instructions below use AWS EC2 instances connected within a Virtual Private Cloud (VPC).
20
21
21
-
Use the commands below to install `iperf3`, a powerful and flexible open-source command-line tool used for network performance measurement and tuning. It allows network administrators and engineers to actively measure the maximum achievable bandwidth on IP networks.
22
+
To get started, create two Arm-based Linux instances, with each instance serving a distinct role:
22
23
23
-
Run the following on both systems:
24
+
* One acting as a client
25
+
* One acting as a server
26
+
27
+
The instructions below use two `t4g.xlarge` instances running Ubuntu 24.04 LTS.
28
+
29
+
## Install software dependencies
30
+
31
+
Use the commands below to install iPerf3, which is a powerful open-source CLI tool for measuring maximum achievable network bandwidth.
32
+
33
+
Begin by installing iPerf3 on both the client and server systems:
24
34
25
35
```bash
26
36
sudo apt update
27
37
sudo apt install iperf3 -y
28
38
```
29
39
30
40
{{% notice Note %}}
31
-
If you are prompted to start`iperf3` as a daemon you can answer no.
41
+
If you're prompted to run`iperf3` as a daemon, answer "no".
32
42
{{% /notice %}}
33
43
34
-
## Update Security Rules
44
+
## Update security rules
35
45
36
-
If you are working in a cloud environment like AWS, you need to update the default security rules to enable specific inbound and outbound protocols.
46
+
If you're working in a cloud environment like AWS, you must update the default security rules to enable specific inbound and outbound protocols.
37
47
38
-
From the AWS console, navigate to the security tab. Edit the inbound rules to enable `ICMP`, `UDP` and `TCP` traffic to enable communication between the client and server systems.
48
+
To do this, follow these instructions below using the AWS console:
39
49
40
-
50
+
* Navigate to the **Security** tab for each instance.
51
+
* Configure the **Inbound rules** to allow the following protocols:
52
+
*`ICMP` (for ping)
53
+
* All UDP ports (for UDP tests)
54
+
* TCP port 5201 (for traffic to enable communication between the client and server systems)
41
55
42
-
{{% notice Note %}}
43
-
For additional security set the source and port ranges to the values being used. A good solution is to open TCP port 5201 and all UDP ports and use your security group as the source. This doesn't open any traffic from outside AWS.
For secure internal communication, set the source to your instance’s security group. This avoids exposing traffic to the internet while allowing traffic between your systems.
60
+
61
+
You can restrict the range further by:
62
+
63
+
* Opening only TCP port 5201
64
+
65
+
* Allowing all UDP ports (or a specific range)
44
66
{{% /notice %}}
45
67
46
68
## Update the local DNS
47
69
48
-
To avoid using IP addresses directly, add the IP address of the other system to the `/etc/hosts` file.
70
+
To avoid using IP addresses directly, add the other system's IP address to the `/etc/hosts` file.
49
71
50
-
The local IP address of the server and client can be found in the AWS dashboard. You can also use commands like `ifconfig`, `hostname -I`, or `ip address` to find your local IP address.
72
+
You can find private IPs in the AWS dashboard, or by running:
73
+
74
+
```bash
75
+
hostname -I
76
+
ip address
77
+
ifconfig
78
+
```
79
+
## On the client
51
80
52
-
On the client, add the IP address of the server to the `/etc/hosts` file with name `SERVER`.
81
+
Add the server's IP address, and assign it the name `SERVER`:
53
82
54
83
```output
55
84
127.0.0.1 localhost
56
85
10.248.213.104 SERVER
57
86
```
58
87
59
-
Repeat the same thing on the server and add the IP address of the client to the `/etc/hosts` file with the name `CLIENT`.
88
+
## On the server
89
+
90
+
Add the client's IP address, and assign it the name `CLIENT`:
| SERVER | Server | Runs `iperf3` in listen mode |
100
+
| CLIENT | Client | Initiates performance tests |
62
101
63
-
Finally, confirm the client can reach the server with the ping command below. As a reference you can also ping the localhost.
102
+
103
+
104
+
105
+
## Confirm the server is reachable
106
+
107
+
Finally, confirm the client can reach the server by using the ping command below. If required, you can also ping the localhost:
64
108
65
109
```bash
66
110
ping SERVER -c 3 && ping 127.0.0.1 -c 3
67
111
```
68
112
69
-
The output below shows that both SERVER and localhost (127.0.0.1) are reachable. Naturally, the local host response time is ~10x faster than the server. Your results will vary depending on geographic location of the systems and other networking factors.
113
+
The output below shows that both SERVER and localhost (127.0.0.1) are reachable.
114
+
115
+
Localhost response times are typically ~10× faster than remote systems, though actual values vary based on system location and network conditions.
70
116
71
117
```output
72
118
PING SERVER (10.248.213.104) 56(84) bytes of data.
0 commit comments