| title | Microbenchmark Existing Network Connection |
|---|---|
| weight | 3 |
| layout | learningpathall |
First we will microbenchmark the bandwidth between the client and server. First start the iperf server on the server node with the following command.
iperf3 -s-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
By default, the server listens on port 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.
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.
iperf3 -c SERVER -V...
[ 5] local 10.248.213.97 port 42176 connected to 10.248.213.104 port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 594 MBytes 4.98 Gbits/sec 0 1.48 MBytes
[ 5] 1.00-2.00 sec 593 MBytes 4.97 Gbits/sec 0 2.07 MBytes
[ 5] 2.00-3.00 sec 592 MBytes 4.97 Gbits/sec 0 2.07 MBytes
[ 5] 3.00-4.00 sec 590 MBytes 4.96 Gbits/sec 0 2.07 MBytes
[ 5] 4.00-5.00 sec 593 MBytes 4.97 Gbits/sec 0 2.18 MBytes
[ 5] 5.00-6.00 sec 591 MBytes 4.96 Gbits/sec 0 2.18 MBytes
[ 5] 6.00-7.00 sec 592 MBytes 4.97 Gbits/sec 0 2.18 MBytes
[ 5] 7.00-8.00 sec 593 MBytes 4.97 Gbits/sec 0 2.18 MBytes
[ 5] 8.00-9.00 sec 588 MBytes 4.93 Gbits/sec 0 2.18 MBytes
[ 5] 9.00-10.00 sec 592 MBytes 4.96 Gbits/sec 0 2.18 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.78 GBytes 4.96 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 5.78 GBytes 4.96 Gbits/sec receiver
CPU Utilization: local/sender 5.3% (0.1%u/5.2%s), remote/receiver 26.7% (1.2%u/25.5%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
iperf Done.
-
The
Cwndstands for the control window size and corresponds to the allowed number of TCP transactions inflight before receiving an acknowledgmentACKfrom the server. This adjusts dynamically to not overwhelm the receiver and adjust for variable link connection strengths. -
The
CPU Utilizationrow shows both the usage on the sender and receiver. If you are migrating your workload to a different platform, such as fromx86toAArch64, there may be subtle variations. -
The
snd_tcp_congestion cubicabdrcv_tcp_congestion cubicvariables show the congestion control algorithm used. -
This
bitrateshows the throughput achieved under this microbenchmark. As we can see from the above, we have saturated the 5 Gbps bandwidth available to ourt4g.xlargeAWS instance.
We 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 we need to observe the statistics on the server side to see the % of packet 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 on video calls.
Run the following command from the client to send 2 parallel UDP streams with the -P 2 option.
iperf3 -c SERVER -V -u -P 2Looking at the server output we can observe 0% of packets where lost for our short test.
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.016 ms 0/147 (0%) receiver
[ 6] 0.00-10.00 sec 1.25 MBytes 1.05 Mbits/sec 0.014 ms 0/147 (0%) receiver
[SUM] 0.00-10.00 sec 2.51 MBytes 2.10 Mbits/sec 0.015 ms 0/294 (0%) receiver
Additionally on the client side, our 2 streams saturated 2 of our 4 cores in the local node.
CPU Utilization: local/sender 200.3% (200.3%u/0.0%s), remote/receiver 0.2% (0.0%u/0.2%s)