Xavier NX Serial Latency

[pierce]

Hi There,

I have a periodic stream of serial data coming into my Xavier NX that seems to work fine when the CPU has a low load average. Once the CPU becomes loaded, I begin to notice high latency in my serial read() calls where they begin to block on the order of ~0.5-1.0s. I know that the serial data is coming in much higher rate than this. I have tried setting the thread priority to the highest for the thread performing the read() calls and still have the same problem.

Is there any tuning I can do to fix this issues?

Thanks for any help you can provide.

[JerryChang]

hello pierce,

it’s by default have baudrate with 115200/8n1,
please have a try with stopping and disabling the nvgetty service. this starts a console on ttyTHS1.
for example,
systemctl stop nvgetty
systemctl disable nvgetty

[pierce]

Hi @JerryChang

Thanks for the response. I am not familiar with the nvgetty service. I tried disabling it and didn’t seem to notice any difference.

[linuxdev]

nvgetty refers to serial console software using the serial device as a terminal. If two different programs try to use the same serial UART at the same time you will no doubt have many problems. If you run this command on the Jetson:
ls -l /dev/ttyS* /dev/ttyTHS*
…then you will notice most of the serial devices are “group” of “dialout”. These are devices not being used by serial console. A device which is group “tty” is already being used by serial console and not eligible to be used by your custom application (until nvgetty is disabled, and then “group” reverts to “dialout” instead of “tty”).

Note that device naming of “ttyS#” and “ttyTHS#” refers to the same hardware if the “#” is the same, but different drivers are used for the hardware depending on if you use the “S#” or “THS#” file.

There could still be latency issues, but if your device is group “dialout”, then basics are ok.

[pierce]

@linuxdev

Thanks, yes the serial ports are of group “dialout”. I am not having any problem with serial port data itself, just the latency can be quite high when the CPU is under high load.

[linuxdev]

The CPU core will be sharing interrupts with other hardware. I’ve never found a good way to reduce latency for hardware which is not able to migrate to another core (hardware IRQ requires the wiring to be in place if it is to migrate to another CPU, but much of the hardware is tied only to the first CPU). I suppose it is possible to force some software to migrate to a non-CPU0 core and reduce load to CPU0 to leave more time for hardware IRQ processing on that core.