Abnormally low FPS on dual RTX PRO 6000 Blackwell workstation across Isaac Sim 4.5.0, 5.0.0, and 5.1.0.

[hangongchen]

Description

Hi Nvidia team,

This is a follow up from post #578 (comment).

We have reinstalled GPU driver to 580.95.05. Unfortunately the low FPS issue still shows up and there isn't any difference.
By the way, the isaacsim is installed in a conda env.

Isaac Sim version

5.1.0

Operating System (OS)

Ubuntu 22.04

GPU Name

RTX PRO 6000 *2

GPU Driver and CUDA versions

580.95.05

Logs

No response

Additional information

No response

[hangongchen]

By simply starting the simulation, the FPS drop to roughly 25.

[ssulkunte-nv]

Hi @hangongchen. Here's a few debugging steps to take:

1. What CPU do you have? If it's on the slower side, can you try to set the CPU governors to a faster mode (i.e. performance mode)? Docs
2. Try launching Isaac Sim with --reset-user to confirm that there are no persistent settings that may have been applied previously causing slower rendering
3. Run a benchmark from the docs and share the metric output here. This can help confirm whether a more GPU-intensive workflow runs as expected (rather than an empty scene). Specifically, I'd recommend to run the Workflow Performance / ROS 2 Render & Publishing Speed benchmark.
4. If still seeing abnormal performance, capture a trace of the slowdown (~10 seconds worth) using the Tracy profiler and share here. That can help identify what specifically on this system seems to be causing the slowdown. Docs here

[hangongchen]

Thanks to your suggestions. Below is what I got:

1. Our CPU is 2× Intel Xeon CPU Max 9480 with performance mode on
2. Tried but it doesn't help
3. Isaac Sim Benchmark Matrix
   Source: benchmark_metrics/kpis_benchmark_scene_loading.json
   Benchmark: benchmark_scene_loading
   Environment: /Isaac/Environments/Simple_Warehouse/full_warehouse.usd
   Command: ./python.sh standalone_examples/benchmarks/benchmark_scene_loading.py --env-url /Isaac/Environments/Simple_Warehouse/full_warehouse.usd
   Timestamp: 2026-05-27T18:57:00.044918
   App: 5.1.0 rc.19 release.26219.9c81211b.gl
   Kit: 107.3.3_production
   GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition
   CPUs: 224

Metric	Loading	Benchmark
Runtime (ms)	113409.427	15836.043
Mean FPS	n/a	54.466
Real Time Factor	n/a	0.63
System Memory RSS (GB)	16.225	16.188
System Memory VMS (GB)	508.238	508.321
System Memory USS (GB)	15.183	15.142
GPU Memory Tracked (GB)	2.135	4.025
GPU Memory Dedicated (GB)	1.229	2.198
Mean App_Update Frametime (ms)	n/a	18.36
Stdev App_Update Frametime (ms)	n/a	2.7
Min App_Update Frametime (ms)	n/a	12.62
Max App_Update Frametime (ms)	n/a	23.3
Mean Physics Frametime (ms)	n/a	1.83
Stdev Physics Frametime (ms)	n/a	0.21
Min Physics Frametime (ms)	n/a	1.4
Max Physics Frametime (ms)	n/a	2.19

4. Github blocks .tracy attachments. Please use this link https://drive.google.com/drive/folders/16Bsd46YolX0USEIeuNSbnRd5EBz1Pi7C?usp=sharing

[ssulkunte-nv]

@hangongchen The benchmark results look fairly normal but the one run is a minimal example so I wouldn't expect it to be slow. Most likely this is because the Intel Xeon CPU Max 9480 has a base clock speed of 1.90 GHz which is unfortunately fairly slow. Running in performance mode should pin the clock speed to 3.50 GHz which should improve that base performance but is still relatively slow. For comparison, the clock speed of the machines tested for Isaac Sim published benchmarking data is close to 6.0 GHz from an Intel i9-14900k.

Regardless, there still may be some possibilities to improve this base performance for your usecase. Unfortunately the shared Tracy file only captures the application initialization, not the runtime. Please capture a new trace, after hitting play on a slow scene, and share here. A simple way to tell, without looking at the Tracy itself, is to check the file size which for a Tracy capture should generally be in the 10s of MB (rather than 100KB).

[LinfengCheng111]

Hi Nvidia team,

I am one member of the same lab as hangong,

I re-captured the Tracy trace following the recommended procedure by starting the capture after pressing Play on the scene and recording approximately 10 seconds of the runtime slowdown.

New Trace file and log have been uploaded here:
https://drive.google.com/drive/folders/1ubBEVWRFqxCG8bS_QiceFm8H35WBHpI7?usp=drive_link

Please let me know if any additional profiling data or a longer capture would be helpful.