TX2 with ethernet camera Linked directly, data dropped seriously, errors: "The buffer was incompletely grabbed"

Recent we are using a ethernet camera directly linking with TX2, However, The FPS is not stable, changing from 2.3FPS to 93FPS.The error information says " The buffer was incompletely grabbed".So i think i should adjust the jumbo frame(a bigger buffer size), but when i run “ethtool -g eth0”, getting “Operation not supported”.So, does it mean i can’t change the jumbo frame?The driver is not support of changing “jumbo frame”?
It troubles me a lot…

On R28.2 I ran this successfully:

sudo link set eth0 mtu 9000
# Verify:
sudo ip link show eth0 | grep mtu

Should smaller packets actually get used while MTU is higher would imply the router or switch or something being traversed has an MRU not accepting that. Try with “ip” instead of “ethtool”.

I tried to do “sudo ip link set eth0 mtu 9000” and “sudo ip link show eth0 | grep mtu”,and i got this

“3:eht0:<BROADCAST,MUTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UPmode DEFAULT group default qlen 1000”

However it seems worse , and the frames changes from 0.7fps to 23fps.
Also, i tried mtu 500/800/1000/1472/9000, All failed ,and got a wrose packet dropped.

PS: My workstation is Jetson-TX2(using jetpack3.2) with BASLER Ethernet Camera(acA1300-60gm)–driver is pylon


I have tried to use it in my X86 computer(ubuntu16.04) with Intel Ethernet Server Adapter X520, with same no extra operation (all is default), it works well,amazing…Does it be the reason that the Ethernent of TX2 is not suit for transforming so much data?(67.9fps ,88.9MB/s)

Do be sure to maximize performance before testing:

sudo nvpmodel -m 0
sudo ~nvidia/jetson_clocks.sh

Always keep in mind that if the other end of the connection (or any hop along the route) does not support jumbo frames, then having an MTU of 9000 won’t force packet sizes of 9000. The MRU can overrule, it is negotiated as to what actually runs. So be sure your receiving end is not forcing non-jumbo frames (check the specs to see if jumbo frames are supported, you won’t see MRU reported the way MTU is).

Understand that there are cases where larger data benefits from this, but smaller data may have increased latency. In some cases there is an attempt to aggregate more data before sending if only small amounts of data are seen relative to frame size. Even if you know your data is large, something like a control channel with small commands to control the camera could be slowed down while waiting for more data to send.

There is a weakness in the current Jetsons where only CPU0 core can be used for some hardware I/O, and may become a bottleneck if you’re running multiple applications requiring hardware I/O at the same time (e.g., multiple users of GPIO, USB, and ethernet all at once, versus something which is purely compute). You’d have to profile to know what is actually slowing things down.

Maximizing performance and Slowing down the bandwidth,decrease the fps to 54FPS actually solve my problem,don’t need to change the MTU. Ago, the cpu frequent is too low to acquire so much data fully.
Best wishes!