Jetson AGX Thor: 25GbE Links Established but Throughput Capped at ~10 Gbps

Hardware: Jetson AGX Thor Dev Kit
JetPack Version: R38.2.1 (latest as of Sep 2025)
Network Setup: 4x25GbE via QSFP28 breakout cable → MikroTik CRS518 switch → Mellanox ConnectX-5 100G
Issue: All 4 ports successfully negotiate 25Gbps, but actual throughput is limited to 8-10 Gbps (peaks at 12.6 Gbps) per port instead of expected ~23-24 Gbps.


Current Status

✅ What’s Working

  • Link establishment: All 4 mgbe ports show Speed: 25000Mb/s, Link detected: yes
  • Hardware offloads: TSO/GSO/GRO all enabled
  • IRQ distribution: Manually pinned to separate CPU cores (0-3)
  • Switch configuration: MikroTik ports at 25G, FEC off, flow control off, zero errors/drops
  • Cables: Mellanox MCP1600-C001 1m DAC breakout cables

❌ The Problem

  • Single stream TCP: 8-10 Gbps average (peaks at 12.6 Gbps)
  • Multi-stream (-P 4): 10.1 Gbps aggregate (marginal improvement)
  • Multi-stream (-P 8): 6.3 Gbps aggregate (WORSE with more parallelism)

Diagnostic Data

System Information

# JetPack version
$ cat /etc/nv_tegra_release
R38 (release), REVISION: 2.1, GCID: 42061081, BOARD: generic, EABI: aarch64, DATE: Wed Sep 10 19:49:31 UTC 2025

# Kernel
$ uname -r
6.8.12-tegra

# Link status (all 4 ports identical)
$ ethtool mgbe0_0
Speed: 25000Mb/s
Duplex: Full
Link detected: yes
Supported FEC modes: Not reported

Performance Tests

# Single stream TCP (best result)
$ iperf3 -c 10.0.0.75 -t 30 -i 5
[  5]   0.00-5.00   sec  5.06 GBytes  8.68 Gbits/sec
[  5]   5.00-10.00  sec  7.34 GBytes  12.6 Gbits/sec   # PEAK
[  5]  10.00-15.00  sec  7.01 GBytes  12.0 Gbits/sec
[  5]  15.00-20.00  sec  4.62 GBytes  7.93 Gbits/sec
[  5]   0.00-30.00  sec  32.5 GBytes  9.32 Gbits/sec   # AVG

# Multi-stream makes it WORSE
$ iperf3 -c 10.0.0.75 -t 15 -P 8
[SUM]   0.00-15.00  sec  11.1 GBytes  6.34 Gbits/sec   # Lower than single stream!

Key Statistics

# ethtool -S mgbe0_0 | grep -E "err|drop" | grep -v ": 0"
mmc_rx_crc_error: 1
mmc_rx_packet_smd_err_cnt: 37
mgbe_payload_cs_err: 1739    # ← KNOWN ISSUE from Orin forums

# CPU load during 9 Gbps test (NOT CPU-bound!)
%Cpu(s):  0.6 us,  1.9 sy,  0.0 ni, 90.6 id,  0.6 hi,  6.3 si
# CPU is 90% IDLE, only 7% interrupt load

# IRQ distribution (properly spread after manual pinning)
$ cat /proc/interrupts | grep mgbe0_0
272: 1127517       0       0       0  mgbe0_0.vm0  # CPU0
273: 1040871  342164       0       0  mgbe0_0.vm1  # CPU1
274:  474624       0  669726       0  mgbe0_0.vm2  # CPU2
275:  174643       0       0  279539  mgbe0_0.vm3  # CPU3

What We’ve Ruled Out

NOT a CPU bottleneck: CPU 90% idle, IRQs only 7%
NOT interrupt saturation: IRQs distributed across 4 cores
NOT the switch: Zero drops, zero errors, proper config verified
NOT FEC mismatch: Both sides report FEC off/unsupported
NOT MTU: Thor at 8966, switch at 9000 (within tolerance)
NOT TCP buffers: Already at 128MB (net.core.rmem_max=134217728)
NOT cable quality: All 8 SFP28 ports on switch show identical 25G links


Suspected Root Causes

1. mgbe_payload_cs_err Counter

The error counter is at 1739 (didn’t increment during testing, but non-zero). NVIDIA forums link this to:

  • Orin thread: “Reduced bandwidth at 10Gbps on Orin and mgbe_payload_cs_err correlation”
  • MACsec driver issues causing latent packet corruption
  • Suggested fix: Rebuild kernel with OSI_MACSEC_EN disabled

Question: Is there a known fix for Thor/r38.2.1? Should we expect a driver update?

2. Multi-Lane (x4) Validation Status

Forums mention Thor x4 mode is “not fully validated yet” (only x1 officially supported). However:

  • Official documentation clearly states 4x25GbE support
  • All 4 ports DO negotiate and establish 25G links
  • Throughput cap suggests partial functionality

Question: What’s the official status of 4x25GbE breakout mode on Thor dev kit? Should we expect ~10 Gbps as current ceiling?

3. Variable Throughput Pattern

Throughput cycles between 7-12.6 Gbps in a sawtooth pattern, suggesting TCP congestion backoff. But:

  • No packet loss detected on switch or Thor
  • Retransmits are minimal (48-58 per 30s test)
  • CPU has plenty of headroom

Question: Is there a known queueing/driver contention issue in early Thor MGBE driver?


Attempted Fixes (No Significant Impact)

  1. ✅ Manual IRQ pinning: echo N > /proc/irq/XXX/smp_affinity_list → Improved from 8.4 to 10.4 Gbps (24% gain, not the 2-3x expected)
  2. ✅ Stopped irqbalance service
  3. ✅ Enabled hardware offloads (TSO/GSO/GRO)
  4. ✅ Increased ring buffers to max: ethtool -G mgbe0_0 rx 16384
  5. ✅ Increased TCP buffers to 128MB
  6. ❌ Interrupt coalescing: Interface must be down, but settings rejected with “Invalid argument”
  7. ❌ Force 10G mode: ethtool -s mgbe0_0 speed 10000 → “link settings update failed”

Questions for NVIDIA

  1. Is 4x25GbE breakout mode fully supported on Thor dev kit (r38.2.1)? If not, what’s the expected timeline for validation?
  2. Is there a known fix for mgbe_payload_cs_err limiting throughput? Should we rebuild kernel without MACsec?
  3. Why does multi-streaming DEGRADE performance? (-P 8 gives 6.3 Gbps vs 10 Gbps single stream)
  4. What’s the expected line-rate performance for current Thor firmware? Is ~10 Gbps per port the current ceiling?
  5. Are there any Thor-specific MGBE driver patches coming in future JetPack releases?

Environment Details

  • Thor: Jetson AGX Thor Dev Kit, JetPack r38.2.1, kernel 6.8.12-tegra
  • Switch: MikroTik CRS518-16XS-2XQ, RouterOS 7.x
  • Cables: Mellanox MCP1600-C001 1m DAC QSFP28 breakout (4x25G)
  • Target: Mellanox ConnectX-5 Ex (100G port, tested stable)
  • Test tool: iperf3 3.16 (multi-threaded)

Full diagnostics available: Can provide complete ethtool output, dmesg logs, or additional tests as needed.

Any guidance would be greatly appreciated - we’re trying to set up a mesh network for distributed AI inference and need full 25G performance. Currently evaluating whether to wait for driver fix or fall back to 10G aggregate.

Thanks!

please run with this

1.sudo  jetson_clock

2. mgbe threaded
# echo 1 > /sys/devices/platform/bus@0/a808a10000.ethernet/net/mgbe0_0/threaded
# echo 1 > /sys/devices/platform/bus@0/a808e10000.ethernet/net/mgbe3_0/threaded
# echo 1 > /sys/devices/platform/bus@0/a808b10000.ethernet/net/mgbe1_0/threaded
# echo 1 > /sys/devices/platform/bus@0/a808d10000.ethernet/net/mgbe2_0/threaded

3. iperf setup

Server

=====

iperf3 -s -B 192.168.10.2 &

iperf3 -s -B 192.168.20.2 &

iperf3 -s -B 192.168.30.2 &

iperf3 -s -B 192.168.40.2 &


client

====

iperf3 -c 192.168.10.2 -i 1 -t 300

iperf3 -c 192.168.20.2 -i 1 -t 300

iperf3 -c 192.168.30.2 -i 1 -t 300

iperf3 -c 192.168.40.2 -i 1 -t 300


1 Like

Thanks Wayne! This successfully improved Thor’s 25GbE performance without kernel rebuild, and discovered/fixed a firmware MAC address bug!

Hardware:

  • Jetson AGX Thor Developer Kit (P3834-0008 + P4071-0000)
  • 4x QSFP28 (25GbE each)
  • Connected to Mellanox ConnectX-5 Ex (100Gb)

Results:

  • Baseline: ~10 Gbps per port
  • Optimized: 17 Gbps per port (70% improvement)
  • All 4 ports working! (aggregate ~68 Gbps)
  • Method: Runtime tuning only (no reflash)

Configuration:

# Enable max performance
sudo jetson_clocks

# Enable threaded NAPI (THE KEY!)
for port in a808a10000 a808b10000 a808d10000 a808e10000; do
  sudo sh -c "echo 1 > /sys/devices/platform/bus@0/${port}.ethernet/net/mgbe*/threaded"
done

# Test with iperf3
iperf3 -c <server_ip> -t 30

Firmware Bug Found:
mgbe1_0 had duplicate MAC address 3c:6d:66:f9:c0:31 (same as mgbe2_0)

  • Expected sequence: 2f, 30, 31, 32
  • Actual sequence: 2f, 31, 31, 32 (missing 30!)

Fix:

sudo ip link set mgbe1_0 down
sudo ip link set mgbe1_0 address 3c:6d:66:f9:c0:30
sudo ip link set mgbe1_0 up

After fix, Port 2 achieves 17 Gbps like the others!

Key Findings:

  • CPU usage: ~90% idle (NOT CPU-bound)
  • Threaded NAPI moves packet processing to kernel threads
  • Achieved 68% of theoretical 25 Gbps per port
  • All 4 ports working after MAC fix

Question: Has anyone pushed past 17 Gbps per port? I suspect MACsec overhead (MTU 8966) might be the next bottleneck.

Patch 1: Disable MACsec

  • File: tegra264-p4071-0000.dtsi
  • Add: nvidia,macsec-enable = <0x0>; to all 4 MGBE blocks
  • Effect: Eliminates payload checksum errors, restores MTU to 9000

Thanks for the guidance!

mgbe1_0 had duplicate MAC address 3c:6d:66:f9:c0:31 (same as mgbe2_0)

This one sounds weird. Do you always see this result in your ifconfig? I mean once you reboot, you will see duplicated mac addr

When you see two devices with the same MAC address, and you examine it with (this is newer than ifconfig, I liked ifconfig better):
ip -s -a addr

In particular, for the two devices which show as the same MAC address, do you see anything other than “0” for collisions? If so, then this could be a dramatic slowdown in networking, or even near-complete failure.

I don’t know about ‘always’ as I don’t know that we’ve looked this closely at all of them because were just trying to get 1 to top speed. I did some customizations above to this unit, but the 2nd one I have I only did the documented 25Gbs patches and that has the same issue. Full details attached prepared by AI. Any thoughts on disabling MACsec to get to 25Gbs or other ideas? Thanks again.

THOR_MAC_BUG_ANALYSIS.txt (5.2 KB)

One just wasn’t working at all and the other dupe was fine. It was fixed right away and was easy to didn’t play around too much with it.

Looks like the mac address issue does not happen with my local device which is upgraded to 38.2.2.

Maybe trying to upgrade it too to see if this is fixed.

I’m not too worried about it. We have a permanent fix in and are on most recent version so I’m not sure what would have caused that. The only changes we made to kernel files were those in the 25 Gigabit Ethernet doc as of now. The changes you suggested got us to 17Gbs and we had identified MACsec disabling as a potential next step to push closer to 25Gbs/port and were going to implement yesterday but came across this topic that is making us 2nd guess that option: Jetpack 6.0: mgbe_payload_cs_err increasing after MACsec removal on orin . Any ideas?

17G is the limit for now. We are still checking this internally.

1 Like

Thanks for the update on this. We’ll play around with it a bit more eventually and see if we can figure something out to unlock the full 25Gbs. Please let me know any updates. Happy to be a guinea pig ;)