Jetson THOR GPU stuck at 1.05GHz

Robotics & Edge Computing Jetson & Embedded Systems Jetson Thor
1

Hi,

it seems that no matter which performance mode is currently active (MAXN or 120W) and even with jetson_clocks activated, the GPU of the Jetson THOR can’t go higher than 1.05 GHz which is lower than the 1.5GHz announced. Is it a known issue and do you know how to fix it ?

Here is the output of the cuda13 sample deviceQuery :

Starting…

CUDA Device Query (Runtime API) version (CUDART static linking)

Detected 1 CUDA Capable device(s)

Device 0: “NVIDIA Thor”
CUDA Driver Version / Runtime Version 13.0 / 13.0
CUDA Capability Major/Minor version number: 11.0
Total amount of global memory: 125772 MBytes (131881619456 bytes)
(020) Multiprocessors, (128) CUDA Cores/MP: 2560 CUDA Cores
GPU Max Clock rate: 1049 MHz (1.05 GHz)
Memory Clock rate: 0 Mhz
Memory Bus Width: 0-bit
L2 Cache Size: 33554432 bytes
Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers
Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 49152 bytes
Total shared memory per multiprocessor: 233472 bytes
Total number of registers available per block: 65536
Warp size: 32
Maximum number of threads per multiprocessor: 1536
Maximum number of threads per block: 1024
Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535)
Maximum memory pitch: 2147483647 bytes
Texture alignment: 512 bytes
Concurrent copy and kernel execution: Yes with 1 copy engine(s)
Run time limit on kernels: Yes
Integrated GPU sharing Host Memory: Yes
Support host page-locked memory mapping: Yes
Alignment requirement for Surfaces: Yes
Device has ECC support: Disabled
Device supports Unified Addressing (UVA): Yes
Device supports Managed Memory: Yes
Device supports Compute Preemption: Yes
Supports Cooperative Kernel Launch: Yes
Device PCI Domain ID / Bus ID / location ID: 0 / 1 / 0
Compute Mode:
< Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >

deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 13.0, CUDA Runtime Version = 13.0, NumDevs = 1
Result = PASS

We are running JetPack7 - Jetson Linux R38.2.1

Thank you

Léo

1 Like
3

please provide your tegrastats result and also dmesg.

4

Hello, thank you for your answer,

I’m sorry I won’t be able to publish my whole dmesg output but if you can tell me what to look for i’ll be glad to transmit that. Here is the tegrastats log.

tegrastats.txt (1.2 KB)

However by running other tests on our end we could understand that it was only a “display error” produced by the cuda c API, since the gpu frequency logged in nsys profiles was the right one (1.5GHz) when in MAXN jetson_clocks. Also when creating custom power modes with different gpu-frequencies, we would always have the deviceQuery sample telling us the frequency is 1.05GHz but the relative performances between the different modes would show us that the frequency was in fact changed.

Thank you,

Léo

5

Are you talking about only cuda deviceQuery reports you 1.05G result while other tool all give you 1.5Ghz at same time?

6

yes, deviceQuery or any executable fetching the clockRate with cudaDeviceGetAttribute from c api

9

Hi,

Sorry for the late update.

By default, Jetson’s GPU uses dynamic frequency. This means the GPU clocks are adjusted based on the loading.

If you want to lock or test the maximum frequency, please run the jetson_clocks to lock it to the maximum.
For example, we can see 1.5 GHz after applying the script:

$ sudo jetson_clocks 
Enabled Legacy persistence mode for GPU 00000000:01:00.0.
All done.

$ sudo tegrastats 
10-08-2025 08:43:13 ... GR3D_FREQ @[1574,1574,1574] ...

Thanks.

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.