Repository navigation
Replies: 1 comment
|
Kit 109 includes streaming improvements, so testing Isaac Sim 6.0.0 would be a useful next step. The 6.0.0 requirements (https://docs.isaacsim.omniverse.nvidia.com/6.0.0/installation/requirements.html) list Linux driver 580.95.05 as tested. I’d recommend coordinating a driver upgrade before testing to establish a validated baseline and reduce uncertainty from the older driver. If the issue persists, could you share the Kit and client logs around the first failure, along with the streaming client version? It would also help to know whether a simple scene remains stable for a comparable duration. If possible, try the same CAD scene over a direct LAN connection to help isolate scene, rendering, or streaming issues from tunnel/network behavior. For the WireGuard connection, please also verify that the advertised streaming endpoint is reachable through the tunnel. |
Uh oh!
There was an error while loading. Please reload this page.
I’m running Isaac Sim 5.1.0 from the official Docker image on a Linux server with an RTX PRO 6000 Blackwell GPU and NVIDIA driver 580.65.06. I use runheadless.sh, Docker host networking, and the native macOS WebRTC Streaming Client. The Mac connects through a WireGuard tunnel; TCP 49100 and UDP 47998 are allowed only through that private path.
Streaming initially worked for hours. More recently, especially while loading or interacting with a CAD-derived USD scene, the image flickers or turns black and controls stop responding. Reconnecting sometimes works, but at other times I have to restart the Isaac Sim container. The container and Kit process remain running, and TCP 49100 is reachable. In one failed-state check, UDP 47998 was not listening; when streaming worked, UDP 47998 was listening and the remote TCP session was established. nvidia-smi showed only the Isaac Sim Kit process on the selected GPU.
Has anyone found a reliable mitigation for this on 5.1.0? Did moving to the 6.0.0 container actually resolve it for you? Is the missing UDP socket during a failed connection a useful clue?
I’m also considering 6.0.0, but its documentation lists Linux driver 580.95.05 as the tested version, while this shared server currently runs 580.65.06. Has anyone verified this exact combination, or should I plan a coordinated driver upgrade before testing 6.0.0?
All reactions