What is the advantage of using "/jetson_clocks.sh" over MAX-N when benchmarking devboards?


I have been advised to use Jetson clocks when benchmarking devboards. I understood that it will fix the max_freq and min_freq to 1300MHz. This is to avoid dynamic frequency scaling.

When using Mode 0 (MAX-N), max_freq = 1300MHZ, min_freq = I do not know.

But, dynamic frequency scaling will only happen when a tripping point has been reached. Also the chances of the fan activation are higher as it is the tripping point with the lowest temperature to reach.

So what will be the advantage of using Jetson_clocks over MAX-N when benchmarking devboards?

To my understanding you should set MAXN mode AND enable jetson-clocks for benchmarking in order to have maximum performance and reproducable result. Without jetson-clocks enabled there is still dynamic clock rate and therefor you might see different performance between to benchmarking runs.

1 Like

Why there is still dynamic clock rate?

Is it possible to use jetson_clocks with other mode, ex: MAX-Q?

hello Aizzaac,

there’re different clock scaling frequency configurations while you enable nvpmodel to change the power modes, you may also refer to Supported Modes and Power Efficiency session to check maximal frequency of each power modes.
jetson_clocks perform overwrites, it’ll check and write the maximum frequency to update current settings.


Lets say I use MAX-N and execute 10 inferences without jetson clocks. At what frequency did processors work? Is it the frequency that appears in the table? Or does a minimal frequency exist? My point is, is the frequency always oscillating between a minimal frequency and a maximal frequency despite doing few inferences?

This is the table with all the max frequencies in MAXN mode:

The “nvpmodel” determines which range of clocks are available, but other than making sure the range currently running is within that range, nvpmodel does not alter the current clock. Imagine you are using a certain clock, and the model changes, and the new model happens to overlap with that clock…then no clock will change. If conditions are such that the clock must raise or lower to remain within that model’s range, then expect the clock to change.

jetson_clocks actually fixes clocks to the the maximum of that range of clocks. If a range of clocks were specified, then running jetson_clocks should fix the frequency to max of that range. Every time you change the model you should expect to follow the model change with jetson_clocks if you want to remain fixed at the maximum of that range. Running jetson_clocks before nvpmodel will usually have different results than running jetson_clocks after nvpmodel.