Hi, NVIDIA experts,
we connected the custom board and xavier with RGMII through a switch SJA1105.
The port is up with 1000M and ping each other is OK.
But in the throughput test with udp by iperf3, the RX packet lost occurs
Hi,
on the SJA1105 switch there were:
PORT 0: TDA4 Board
PORT 1: Xavier AGX
PORT 3: computer with ubuntu18.04
the test result is :
PC<->TDA4: both directions are normal;
PC<->xavier: from PC to Xavier is normal, from PC to Xavier is lost.
TDA4<->xavier: from Xavier to TDA4 is normal, from TDA4 to Xavier is lost.
It shows when Xavier is the receiver the UDP will be lost.
—when testing with iperf3.1.3, if adds the -l option with more than 4k bytes, it is obviously bad that is more than 90% was lost. With ‘-l 1K’ it was good performace that less than 1% was lost.
We have checked the configuration of the sja1105 switch. PORT0 and PORT1 has same configuration. So that the xavier may has something wrong.
Is there Any advise? Thanks a lot.
The hardware uses the RGMII interface, we think it is unlikely to be a hardware design problem based on the following test results:
The network ports are connected, and data can be sent and received normally, and when small packets (<=2KBytes) of UDP are sent to Xavier, they can reach more than 930Mbit/s.
Serious packet loss only happens when sending UDP large data packets (>2KBytes).
The TCP transmission rate is also normal for large data packets (8KBytes/s), although there are retransmissions.
So that the clock and data link on the hardware are normal.
The following is the design of the xavier hardware, please help to check:
A .What is wrong? How the design can be used normally?
B . Could you provide the hardware design schematic diagram of the Xavier’s official development board?
Hi, have you ever tested xavier connecting with MAC-MAC connection, like xavier to switch? we found this issue on xavier connecting to switch, it works fine when connecting to an ethernet phy. These two kinds of connection is the same which is RGMII.
Hi, This post is also testing with PHY, could you show the result of MAC to MAC mode testing, especially with the HDMI port unplugged?
And we can’t use 5.0.2 now, is there any patch for switch in the JetPack 4.6.2?
You can add similar “fixed-link” node to your jetpack4.6.2 device tree. That was what I tried to say.
Also, HDMI port is not related to EQOS driver. If that happened to your board, please review your hardware, device tree and make sure your HDMI hpd pin is in use by EQOS interrupt…
Hi,
We checked our design diagram, the HDMI was not conflict with EQOS, Is there any procedure that HDMI will do to set the ethernet when it is connected?
It is emergency to solve the problem, could you please help of more advises?
I think the logic here is a little bit wrong. My point is you should toggle these pins and see which one is making your ethernet functionality working (or not work). But not totally removing them.
I can guarantee that the driver for display is not relevant to ethernet driver. The only chance here may be some pin are shared here… so you need to see which pin is that first.
Hi, you can also check the signal quality. There is compliance test guide as below for your reference with which you can check if the signals quality is good enough.
Hi,
with JetPack 5.0.2, we use iperf3 command to test ethernet and it’s OK with unplugged HDMI connection, I can confirm that it is a software issue. Could you give one PATCH that we can use with JetPack 4.6.1 ?