I’m using a USB3 camera that interfaces with the uvcvideo driver on a Linux-based system. The camera generally works fine, but I’m experiencing occasional frame drops of about 130ms, seemingly at random intervals.
I enabled the uvcvideo kernel trace, and during the drops, I consistently see the following messages (spammed) for the 130ms:
spammed messages
- Frame complete (overflow)
- Dropping payload (out of sync)
and sometimes this error at the start of dropping sometimes not
- Marking buffer as bad
This suggests that the UVC data path isn’t being serviced fast enough at times.
What I’ve Tried
After some investigation, I suspected a scheduling or CPU contention issue. Here’s what I did:
Pinned the xhci interrupt to a single core.
Set the uvcvideo-related kworker threads to SCHED_FIFO with priority 99.
After these changes, the problem is completely resolved. No more dropped frames or bad buffers.
The Problem
The uvcvideo driver dynamically spawns and destroys kworker threads during runtime, depending on load or stream state. This makes it difficult to permanently set real-time priority on the right threads, since new ones can appear with default scheduling (SCHED_OTHER).
I could write a user-space daemon/service to monitor and patch these kworker threads as they spawn, but that feels like an ugly workaround.
Questions
Is there a way to modify the default priority/policy of kworker threads, particularly those spawned by uvcvideo?
Could this be a known issue with USB3 + UVC on certain platforms (e.g., Jetson/XHCI bottlenecks)?
Is there a better or more canonical way to ensure low-latency, real-time behavior for UVC streams on Linux?
System Details
USB3 camera (UVC compliant)
Latest Jetpack version 36.4.4 , and tried it on 36.4.3 gives same problem
Hi,
Please execute $ sudo jetson_clocks and see if there is further enhancement. And if the camera source supports UYVY, you can try nvv4l2camerasrc plugin as suggested in Jetson AGX Orin FAQ
Hi DaneLLL,
Thank you for your reply, jetson_clocks is running and i’m running on 8 cores with max power mode, also unfortunately camera doesn’t support UYVY, below is the supported format from the camera source [0]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps)
Hi,
I’m using reComputer J401 -Carrier Board for Jetson Orin NX/Orin Nano, with the provided power supply using the DC jack.
and same problem can be reproduced on other custom made carrier, both powered externally.
steps to reproduce:
1- enable uvc trace
2- run any streaming pipeline from camera
3- run apt update, or apt install cuda-toolkit-12-6 for example or any apt process
4- in dmesg you’ll see some drops with the errors mentioned above
5- sudo dmesg -w | grep -E “overflow|Dropping|error”.
the camera also is using bulk mode, because i couldn’t reproduce it on other camera that uses isochronous mode, while it can be easily reproduced on 2 different cameras on bulk mode
Hi,
Is reComputer J410 designed same as Orin Nano developer kit to have embedded USB hub with 4 type-A ports? If yes, please connect only single USB3 camera and give it a try. The four type-A ports shares one USB3 roothub so if there are other USB2/USB3 devices, the throughput may be impacted.
Hi,
Performance may drop due to concurrent access of multiple USB devices. Because you observe it by only streaming single camera, we can eliminate this. Another possible reason is signal quality is not good. Have you done compliance test to the camera? Would be great if you can share vendor and product ID of the camera for reference.
The camera i’m using now is Active Silicon Harrier camera
idVendor==“0403”,idProduct==“602a”
, I also tried different and shorter cables, when i set the UVC kworker threads priority to SCHED_FIFO rt prio, i barely see the drops, so i believe it’s not regarding the signal quality!
Hi,
We are uncertain how to set UVC kworker threads priority to SCHED_FIFO rt prio permanently. This would need other users to share experience.
One thing you may try is to set isolcpus in /boot/extlinux/extlinux.conf, to have one dedicated CPU core, and call taskset(1) - Linux manual page to launch the gstreamer application on the specific core. See if performance is better if it is run on a dedicated CPU core.
Hi, Thanks for your reply,
i tried that for pinning the XHCI irq, and used a cpu shield for the gstreamer application but the main problem was in uvc threads,unfortunately the uvc spawn these threads on different cores not the isolated ones i’m not sure how to isolate the uvcvideo threads itself