tegrastats, nvpmodel and jetson_clocks
on Jetson Orin Nano and Orin NX.

tegrastats

Prints one line of statistics per interval: RAM and swap, per-core CPU load and frequency, memory controller and GPU load, engine activity, temperatures and power rail readings. NVIDIA ships it preinstalled (Tegrastats Utility).

nvpmodel

Shows and sets the power mode. A mode sets limits on the CPU, GPU and memory clocks and the number of online cores, and it stays set across power cycles (supported modes, power mode controls).

jetson_clocks

Sets the CPU, GPU and EMC clocks to the static maximum of the current power mode. It can also show, store and restore clock settings (Maximizing Jetson Orin Series Performance).

jtopThird party

Part of jetson-stats on GitHub. Its README describes jtop as a terminal tool that monitors the CPU, GPU, memory, engines and fan and can control the nvpmodel mode, fan speed and jetson_clocks, with a Python library alongside. It is a separate install, not part of L4T or JetPack, and this page does not cover it further.

L4T also puts an NVIDIA icon on the right of the Ubuntu desktop’s top bar. It shows the current power mode, switches modes, opens tegrastats in a terminal and starts the Jetson Power GUI (nvpmodel GUI).

NVIDIA documents tegrastats output one statistic at a time, as a format with placeholders and a description (Reported Statistics). These are the fields you will read most on an Orin Nano or Orin NX, each in the format NVIDIA documents for it. X, Y, Z and N are NVIDIA’s placeholders.

That table does not list the timestamp. NVIDIA’s sample output in its validation guide starts the line with the date and time, then the RAM field (Running the tegrastats Command).

RAM

RAM X/Y (lfb NxZ)

X is RAM in use and Y is the total available to applications, both in MB. lfb is the largest free block: the biggest contiguous piece of physical memory that can be allocated right now. N free blocks of Z MB each. It shrinks as memory fragments.

SWAP

SWAP X/Y (cached Z)

Swap in use, total swap available, and swap cached, all in MB.

CPU

CPU [X%@Z,X%@Z,...]

One entry per core: its load as a percentage, then its current frequency Z in MHz. A core that is powered down shows as off. NVIDIA calls the percentages rough approximations, worked out from idle time in /proc/stat.

EMC_FREQ

EMC_FREQ X%@Y

The external memory controller, which every system memory access goes through. X is the share of memory bandwidth in use relative to the current EMC frequency, and Y is that frequency in MHz.

GR3D_FREQ

GR3D_FREQ X%@[Y,Y,...]

The GPU. X is the proportion of the sample period the GPU was active. Each Y is the frequency in MHz of one of the GPU’s GPCs, and all GPCs report the same percentage.

Temperatures

X@YC

One reading per processor block: the block name, then its temperature in degrees Celsius, read from /sys/devices/virtual/thermal/thermal_zone<x>/temp. The zones come from the BSP. For Orin, NVIDIA’s BSP defines cpu-thermal, gpu-thermal, cv0-thermal to cv2-thermal, soc0-thermal to soc2-thermal, tj-thermal and PMIC-Die (NVIDIA’s thermal zone table).

Power rails

VDD_X YmW/ZmW

The rail name, then the rail’s current power and its average power, in milliwatts. Section 04 covers which rails an Orin Nano or Orin NX module has.

VIC

VIC X%@Y

The engine that does video post-processing, producing the final image for a video player’s window. X is its load as a percentage of its current frequency, and Y is that frequency.

NVDEC

NVDEC0 X%@Y

The hardware video decoder: utilization, then frequency in MHz. NVIDIA notes that it is shown only while the hardware decoder or encoder is in use.

NVJPG

NVJPG0 X%@Y

NVIDIA’s JPEG encoder and decoder: utilization, then frequency in MHz. A second instance reports as NVJPG1.

OFA

OFA X%@Y

The optical flow accelerator: utilization, then frequency in MHz.

APE

APE Y

The audio processing engine. Y is its frequency in MHz.

NVIDIA also documents fields for the video encoder (NVENC0 X%@Y), the deep learning accelerator (NVDLA0 X%@Y) and the programmable vision accelerator (PVA0_FREQ [X%,X%]@Y). These only apply to a module and power mode that has the engine. NVIDIA’s supported modes table gives the DLA and PVA core count for each module and mode, and the NVENC clock for each module. It shows no DLA or PVA cores and no NVENC clock on the Orin Nano 4GB and Orin Nano 8GB, and PVA cores in only some modes on the Orin NX 8GB and Orin NX 16GB (NVIDIA’s supported modes table).

NVIDIA’s page also lists an example value for each field. Those examples are not labelled with a module, so treat them as examples of the format rather than numbers to expect from an Orin Nano or Orin NX. Your own output is the reference for your module and power mode.

tegrastats writes one line per interval. --interval sets the interval in milliseconds (default 1000), --logfile sends the lines to a file instead of the terminal, and a trailing & runs it in the background. --stop stops any running instance, and --verbose prints extra messages, including warnings about read failures (command line options).

sudo -v                                           # cache sudo first; the next line runs in the background
sudo tegrastats --interval 1000 --logfile ~/run-01.log &
# ... run your workload ...
sudo tegrastats --stop

NVIDIA’s own validation steps run it as sudo tegrastats (Test Plan and Validation), and the commands here do the same. In the foreground, Ctrl+C stops it. Use a new log file name for each run so runs stay separate.

Turning a log into CSV

A short Python script does it. This one pulls RAM in use, memory controller and GPU load, and every VDD_ rail with its current and average reading. The time column is the date and time at the start of each line, copied as printed. If a line has no timestamp, the script writes a t_ms column instead, counted from the interval you pass, which assumes one line per interval.

# tegrastats_to_csv.py
# usage: python3 tegrastats_to_csv.py ~/run-01.log 1000 > run-01.csv
import csv, re, sys

log_path, interval_ms = sys.argv[1], int(sys.argv[2])
stamp = re.compile(r"(\d{2}-\d{2}-\d{4} \d{2}:\d{2}:\d{2}) ")
fields = {
    "ram_used_mb": re.compile(r"RAM (\d+)/"),
    "emc_pct": re.compile(r"EMC_FREQ (\d+)%"),
    "gr3d_pct": re.compile(r"GR3D_FREQ (\d+)%"),
}
rail = re.compile(r"(VDD_\w+) (\d+)mW/(\d+)mW")

rows = []
with open(log_path) as log:
    for i, line in enumerate(log):
        match = stamp.match(line)
        # the date and time tegrastats printed, or the line's offset if it printed none
        row = {"time": match.group(1)} if match else {"t_ms": i * interval_ms}
        for name, pattern in fields.items():
            match = pattern.search(line)
            row[name] = match.group(1) if match else ""
        for name, now_mw, avg_mw in rail.findall(line):
            row[name + "_mw"] = now_mw
            row[name + "_avg_mw"] = avg_mw
        rows.append(row)

columns = list(dict.fromkeys(key for row in rows for key in row))
out = csv.DictWriter(sys.stdout, fieldnames=columns, restval="")
out.writeheader()
out.writerows(rows)

tegrastats inside a container

tegrastats is installed on the Jetson itself, so the simplest place to run it during a measurement is the host. Inside a container, fields can go missing: in this NVIDIA Developer Forums thread, EMC_FREQ and GR3D_FREQ read 0 inside a container while the host reported them, and the thread records the workaround an NVIDIA moderator gave. If you work in containers, also check your JetPack and L4T version on the host.

tegrastats labels each power reading with a rail name, and NVIDIA’s tegrastats page points to the power-monitor section of its power and performance guide for those names. For the Orin NX and Orin Nano series, that section says the module carries a three-channel INA3221 power monitor at I2C address 0x40, with these channels (NVIDIA’s Orin NX and Orin Nano power monitor section):

VDD_IN

NVIDIA’s description is “Total Module Power”.

VDD_CPU_GPU_CV

The CPU, GPU and CV cores. NVIDIA names the CV cores as the DLA and PVA.

VDD_SOC

The SoC core, which supplies the memory subsystem and engines such as NVDEC, NVENC, VI, VIC and ISP.

NVIDIA also sets average and instantaneous power limits on VDD_IN to keep the module inside its thermal design power (TDP) budget. When the module goes over them, it throttles the CPU and GPU clocks in hardware for a configurable period. If your clocks drop under load, NVIDIA documents counters for these overcurrent (OC) events (Overcurrent Event Status):

grep "" /sys/class/hwmon/hwmon<x>/oc*_event_cnt

You can read the same channels straight from sysfs. in1_label is the rail name, in1_input is its voltage in millivolts and curr1_input its current in milliamperes, where <x> is a dynamic hwmon index:

cat /sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon<x>/in1_label
cat /sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon<x>/in1_input
cat /sys/bus/i2c/drivers/ina3221/1-0040/hwmon/hwmon<x>/curr1_input

Read these nodes, do not write to them. NVIDIA warns that modifying any INA3221 sysfs node value can damage the device (NVIDIA’s note).

sudo nvpmodel -q                     # current power mode
sudo nvpmodel -q --verbose           # current mode and its settings
grep POWER_MODEL /etc/nvpmodel.conf  # every mode this board's config defines
sudo nvpmodel -m <id>                # switch to mode <id>
/usr/sbin/nvpmodel -h                # all options

The modes live in /etc/nvpmodel.conf. Each one is a block that starts with a < POWER_MODEL ID=<id> NAME=<name> > line, which is why the grep above lists them. The NVIDIA desktop icon also lists the modes, in its Power mode submenu (Power Mode Controls, nvpmodel test steps).

After nvpmodel -m, the module stays in that mode until you change it, including across power cycles. Some changes need a reboot. The GPU’s tpc_pg_mask can only be set before the GPU golden context is created, so if the new mode needs a different mask, nvpmodel warns that a reboot is required and asks whether to reboot now. The new mode takes effect after the reboot. You also cannot change the mode after running jetson_clocks without rebooting (section 07).

You can add your own modes to /etc/nvpmodel.conf. Each needs a unique ID. CPU frequencies in the file are in kilohertz; GPU and memory controller frequencies are in hertz. Test your workload to decide how many cores to keep online and which frequencies to set.

Mode numbers do not carry over from one module or board to another. NVIDIA’s own table shows it (NVIDIA’s supported modes table, L4T r36.5):

• the same mode ID stands for a different power budget on different modules;
• the modules do not all offer the same number of modes;
• the default mode is ID 0 on some modules and a different ID on others;
• the modes on offer also depend on the flash configuration the module was flashed with.

So do not assume mode 0 is the top mode. In NVIDIA’s table it is on some modules and configurations and is not on others. A carrier board’s BSP picks the flash configuration and can ship its own nvpmodel.conf, and that file is where the list on a given board comes from. A mode table written for NVIDIA’s developer kit is a starting point, not the answer for another carrier board. Run nvpmodel -q and read /etc/nvpmodel.conf on the board you have.

This page does not list modes for the CB302B Jetson Orin Nano and Orin NX carrier board. Query them on the board. If you are still picking a module, how to choose a Jetson module starts with memory and workload.

jetson_clocks sets the CPU, GPU and EMC clocks to static maximum frequencies. The maximum is whatever the current nvpmodel mode allows, so it pins the clocks at that mode’s ceiling rather than raising the ceiling. It lives at /usr/bin/jetson_clocks (NVIDIA’s jetson_clocks section).

sudo jetson_clocks --show      # current clock settings
sudo jetson_clocks --store     # save them (default file: ${HOME}/.jetsonclocks_conf.txt)
sudo jetson_clocks             # pin CPU, GPU and EMC at the mode's maximum
sudo jetson_clocks --restore   # put the stored settings back

--store and --restore both take an optional file name. Since release 32.4 jetson_clocks no longer sets the fan to maximum by default; --fan does that (NVIDIA’s note). After running jetson_clocks you cannot change the nvpmodel mode until you reboot.

It does not survive a reboot. NVIDIA’s own frequency scaling check starts by making sure jetson_clocks is not active, and says a reboot is enough to do that (Check DVFS Scaling).

Leave it off when you measure power

With jetson_clocks on, the clocks sit at the mode’s maximum whether the workload needs them or not, so the frequency scaling that normally lowers clocks at light load is out of the picture. A power reading taken that way describes the pinned setup, not how the same workload runs under the power mode alone. Reboot (or --restore settings you stored beforehand) before you log a power run, and note the nvpmodel mode alongside the log.

The CB302B runs from 45 W USB-C PD or from hot-swappable Milwaukee M12 battery power, using genuine Milwaukee M12 packs. An internal bridge keeps the board powered while you swap a pack.

On a pack, nvpmodel is the main setting you control from software: the mode sets limits on the module’s clocks and online cores. Choose the mode for your workload on the bench, confirm it with nvpmodel -q, and keep jetson_clocks off unless you need pinned clocks.

For the pack itself, see battery monitoring on the CB302B. As that page describes it, the curve-extras package adds a battery icon with real state of charge in the GNOME taskbar, and its curve-diag tool reports IMU sensor readings and battery status. curve-extras v0.2.0 was built for Orin NX on CB302B, JetPack 6.2.2, L4T 36.5, kernel 5.15.185-tegra; check its requirements before installing.