Hello Everyone,
I am using Jeston NX Xavier on my custom carrier board. The carrier board designed based on Jetson NX xavier design document. However I have observed some packet loss when I operate Ethernet at 1000Mbps and No packet loss at 100Mbps. A 936378617 RJ45 connector is used on our carrier board (Schematic attached below). Further I also tried with 2250015-3 and observed same behaviour.
What should I do to achieve good performance (Zero packet loss) at 1000Mbps ? Is there way to achieve zero packet loss without changing hardware (By changing firmware)?
Note : VCC Connected to 3.3 V and GND connected directly to PCB 3.3 V Ground.
Thanks in advance.
If it is a hardware issue I probably can’t help. However, after some errors have occurred, it would be good to show the output of “ifconfig” to see some of the statistics and narrow down the error behavior. If this is networking to another local Linux computer, then you might also want to post the output of ifconfig on that computer as well to see which side sees which particular error.
Thanks for the reply,
Please see the output of ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::4ab0:2dff:fe05:bff0 prefixlen 64 scopeid 0x20<link>
ether 48:b0:2d:05:bf:f0 txqueuelen 1000 (Ethernet)
RX packets 30148 bytes 38461644 (38.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50 bytes 9844 (9.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 37
Complete ifconfig output:
br-bbf303e2d8e9: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
ether 02:42:0b:a7:fb:c4 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:26ff:fe77:e2ae prefixlen 64 scopeid 0x20
ether 02:42:26:77:e2:ae txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21 bytes 2860 (2.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::4ab0:2dff:fe05:bff0 prefixlen 64 scopeid 0x20
ether 48:b0:2d:05:bf:f0 txqueuelen 1000 (Ethernet)
RX packets 721984 bytes 921648296 (921.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 276 bytes 78386 (78.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 37
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 84452 bytes 6739782 (6.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84452 bytes 6739782 (6.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether ae:8a:f5:43:3c:6d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether ae:8a:f5:43:3c:6f txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth4d8312f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::98ec:36ff:fed8:c679 prefixlen 64 scopeid 0x20
ether 9a:ec:36:d8:c6:79 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 40 bytes 5448 (5.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 10.9.0.161 netmask 255.255.255.255 destination 10.9.0.161
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1 (UNSPEC)
RX packets 2 bytes 184 (184.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 912 (912.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.6.117 netmask 255.255.255.0 broadcast 192.168.6.255
inet6 fe80::32aa:d975:89f6:5c43 prefixlen 64 scopeid 0x20
ether 74:d8:3e:44:86:c1 txqueuelen 1000 (Ethernet)
RX packets 2892 bytes 2787987 (2.7 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 663 bytes 81590 (81.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions
Is 936378617 RJ45 connector suitable for Jetson NX XAVIER (RTL8211FDI PHY controller)?
Those logs did not show any network issue. Were they all from the Jetson? These are the statistics I look at:
RX packets 30148 bytes 38461644 (38.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50 bytes 9844 (9.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The address was assigned, there was significant traffic, there were no drops, errors, overruns, collisions, etc…
It would be good to find out what the other half of the communications shows. If those other logs are from the other computer, then those do not show issues. It is possible for the network to be working and sending perfectly well at one end, but the other end, after successfully seeing the data, could drop that data for various reason.
Another possibility is that you have set it for gigabit, but then the interface reverted back to 100 Mb/s. After the system appears to slow down, what do you see from:
ethtool eth0
(you might need to “sudo apt-get install ethtool”)
Yes, all the data from jetson only. The data flows as follows:
Lidar (Ouster )…RJ45 (936378617)…jetson NX XAVIER.
Sudo ethtool etho is showing 1000Mbps.
Further i tried using iperf3 (server and host method).
When I try to send 1Gbps data from laptop but on the jetson it is showing 0.5Gbps.
In sometimes it is showing 0.2Gbps.
Yes, all the data from jetson only. The data flows as follows:
Lidar (Ouster )…RJ45 (936378617)…jetson NX XAVIER.
The output of sudo ethtool eth0:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes
The Ethernet did not automatically change to 100Mbps. We have put the Ethernet to 100Mbps using below command to know where the complete system working without packet loss.
sudo ethtool -s eth0 speed 100 duplex full autoneg off
Does the LIDAR itself use a lot of bandwidth? Is the LIDAR the primary reason for looking at bandwidth? Does the LIDAR connect directly to the Jetson without a switch?
On the laptop case, after an issue with low bandwidth under gigabit setting, can you run and show the “ifconfig” and ethtool for the laptop net device as well?
Do note that in some cases the CPU itself might be limiting speed. The nature of the data can drastically change efficiency as well. For example, if one repeatedly sends one byte, then the buffer accumulates; then, after either a timeout or reaching sufficient buffer size, a send occurs. This takes a lot of time. The inverse case is that if data is large, then only part of the data fills the buffer, it sends, and the other end holds onto that data…then when the next segment occurs, it appends that data at the recipient end. Eventually the data gets completed and used. That reassembly can take a lot of CPU resources and can slow things down.
Sometimes setting the MTU to a lower value makes things more responsive for small data, or setting jumbo packets works for improving large data. It is a case-by-case answer, and within one data set (which can vary) the answer might change and you might not be able to get complete efficiency for some data. Knowing more about the other half of the connection is needed to know if it is more than just a data-driven latency.
Thanks for your response,
one thing I need to bring it here that the same setup we tested on Jetson NX XAVIER dev kit (carrier) board and observed zero packet loss with lidar and 0.93Gbps data transfer from laptop to Dev kit board.
The only difference from my carrier board (we designed PCB) and Jetson NX XAVIER Dev kit is RJ45 Ethernet connector.
Board Connectors part number
My PCB board 936378617
Jeston NX XAVIER Dev kit A70-112-331N126
Please see internal schematic of both the connectors.
Will RJ45 connector creating the problem ?
I think in my case there is no buffer concept, since Lidar I connected directly to Jetson through RJ45 connector.
Bandwidth : I think bandwidth will also not problem, since the same lidar and laptop is working on jetson NX Xavier dev kit.
I can’t specifically answer this, there is so much involved in simple layout choices (it could be the connector, but more likely it is layout). RF with square waves changes everything. Noise and timing issues can easily cause complete failure and loss.
The RJ45 could indeed be an issue, but basically you would need to simulate the RF characteristics of the board. Seemingly minor changes in trace lengths, trace separation, proximity to other circuitry, capacitance, so on, become very important at higher speeds. Even if the design is perfect, the component placement can be critical. The design guide will provide trace length maximums, impedance, so on, and these really have to be followed.
The range of videos and content related to this is enormous. A couple of YouTube authors which have good content directly related to this:
This is a playlist I would recommend:
https://www.youtube.com/watch?v=ySuUZEjARPY&list=PLIIq_t5YVnB9WAT3eyW4WAsTIjeO3F_w0
I suggest you go to both of those authors’ YouTube pages. Click on videos. The videos listed are “on demand”, and so they don’t all appear unless you scroll down. Keep scrolling down until no more videos show up (that’s a lot of scrolling). Then look for anything with terms:
- Ground.
- Crosstalk.
- RF.
Some specific URLs:
Note that even apps like KiCAD have features available related to this. Even if you don’t use Altium, this all applies. There are some open source emulation tools as well.
Thanks for sharing valuable information and materials. Few of them I have already watched.
Today I soldered 2337992-8 RJ45 connector on same carrier (my PCB) in place of 936378617 RJ45 and observed zero packet loss at 1000Mbps and also 0.95Gbps data receiving when I use Iperf3.
Packet loss could be due to the RJ45 connector since it was working after changing RJ45 connector.
The main difference between them is centre tapped capacitor on pcb side pins. Attached images for your reference.
If it works, then the issue is solved. Center tapped probably gives a better ground return path.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.