**Orin-Nano GBE fails to reach expected throughput in iperf3 TCP bidirectional test**

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hardware Information

  • Module: Jetson Orin-Nano 4GB
  • L4T Version: R36.4.4
  • Link: GBE. Link negotiated at 1000M Full Duplex with auto-negotiation enabled.

image

Pre-test commands executed before each measurement:

sudo nvpmodel -m 0

sudo jetson_clocks

Test command executed on Orin-Nano:

iperf3 -c <server_ip> -p 5201 -b 1G -t 60 --bidir

In TCP bidirectional iperf test (Orin-Nano as client): Aggregate total throughput only reaches around 700Mbps, cannot hit gigabit total capacity.

Are there any recommended tuning methods for GBE on Orin‑Nano R36.4.4 to achieve aggregate TCP bidirectional throughput above 900 Mbps?

4

Hi,

Since the Ethernet link is negotiating at 1000 Mbps full duplex, I would suggest checking whether the throughput limitation occurs in one direction or only when transmitting and receiving simultaneously.

A 1GbE full-duplex connection can theoretically support 1 Gbps in each direction concurrently, although actual TCP throughput will be lower because of protocol overhead.

Could you try the following tests separately?

1. Jetson transmitting:

iperf3 -c <server_ip> -t 30

2. Jetson receiving:

iperf3 -c <server_ip> -t 30 -R

3. Bidirectional test:

iperf3 -c <server_ip> -t 30 --bidir

For TCP testing, omitting -b 1G removes the explicit application-level bitrate limit.

It would also be useful to identify the Ethernet controller and driver:

sudo ethtool -i <interface>
uname -r

Thanks,

Steven Avila

Embedded Software Developer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com

5

TCP single-direction transmit or receive can both reach 900 MB/s. However, in bi-directional traffic, the transmit side is limited to only 750 MB/s.

image
image993×509 105 KB

6

Hi,

Thanks for sharing the information.

The output confirms that your Ethernet interface (enP8p1s0) is using the Realtek r8168 driver (version 8.053.00-NAPI) with kernel 5.15.148-tegra.

Since this is a PCIe-based Ethernet controller, interrupt handling could be worth investigating.

Thanks,

Steven Avila

Embedded Software Developer at RidgeRun

7

It has only one hardware interrupt.

8

(Disclaimer: Assistance generated with AI support for Linux network stack tuning on Jetson platforms).

Getting ~700 Mbps aggregate during a simultaneous TCP bidirectional (--bidir) test on a 1GbE interface is common on embedded ARM64 platforms.

When running bidirectional traffic, the network controller and CPU must handle heavy simultaneous RX and TX interrupt processing, softirqs, and TCP socket buffer context switching. On resource-constrained embedded cores, this creates CPU bottlenecking and packet queue contention before hitting wire speed.

Here are the key network tuning steps you can apply to push bidirectional throughput closer to line rate (~940+ Mbps):

1. Optimize NIC Ring Buffers (ethtool)

Check your current Ethernet driver ring buffer sizes and increase them to prevent packet drops during heavy bursts:

# Check current ring buffer settings
ethtool -g eth0

# Set RX and TX ring buffers to maximum supported values (example)
ethtool -G eth0 rx 4096 tx 4096

2. Adjust Interrupt Coalescing

Lowering interrupt coalescing can improve throughput under high packet rates, though it slightly increases CPU usage:

# Disable adaptive coalescing and tune rx/tx usecs
ethtool -C eth0 adaptive-rx off adaptive-tx off rx-usecs 15 tx-usecs 15

3. Tune Linux Kernel TCP Socket Buffers

Increase default and maximum TCP socket buffer sizes to allow better window scaling during concurrent bidirectional streams:

Add these lines to /etc/sysctl.conf (or apply them temporarily via sysctl -w):

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 10000

Apply the changes with:

sudo sysctl -p

4. Enable Jumbo Frames (If Supported by Switch/Peer)

If your network switch and peer testing machine support Jumbo Frames, increasing the MTU to 9000 drastically reduces the total packet count and lowers CPU interrupt overhead:

sudo ip link set eth0 mtu 9000

5. iperf3 Stream Tuning

When running iperf3, explicitly defining parallel streams (-P) or increasing the TCP window size (-w) often yields more stable aggregate results than a single monolithic bidirectional stream:

iperf3 -c <server_ip> -p 5201 -t 60 -P 4 --bidir
9

thanks.

I have completed the tests following the above method (adaptive is not supported). The bidirectional TCP throughput shows 800 Mbits/s for transmission and 940 Mbits/s for reception, which still fails to meet the target requirement of over 900 Mbits/s for transmission.