Run tegrastats only once and not loop

I want to run tegrastats and parse the output in another program–once. The issue is that tegrastats has no option to only run once, print the output, then exit. It always enters an infinite loop which means I have to go through the headache of forking, executing tegrastats, then killing it with a signal. Is there a way to turn off the looping in tegrastats to avoid the fork? If not, there definitely should be. As a comparison, I’d like to run tegratstas like top -n1 where the n1 argument tells top not to repeatedly update.

hello rtrahan504 ,

may I know what’s your use-case, you may parse sysnode if you’re going to check the reported value only one-time.

This is part of a design study for a NASA JPL satellite using multiple Jetson Xavier AGXs in space. (Any extra Nvidia consultation available would be GREATLY appreciated!!! Hint.) I wish to get telemetry (power, temperature, freq) at specific times when specific kernels run. This would be extremely easy with something like the SMI API, but that doesn’t exist for the Jetson.

I considered reading from the file system for specific pieces of telemetry as noted in https://static5.arrow.com/pdfs/2018/12/12/12/22/1/565659/nvda_/manual/jetson_agx_xavier_thermal_design_guide_v1.0.pdf ; however, according to the forums and documentation the file system entries are inconsistent and some documentation is wrong. The file paths mentioned in the documentation and forums do not correspond to my Jetson development board, and some users have mentioned various paths for each field. That said, I cannot get software approved for space flight which relies on undocumented behavior, thus I’m stuck using tegrastats.

For example, documentation says cat /sys/bus/i2c/drivers/ina3221x/0-0040/iio_device/in_voltage0_input as an example but that path doesn’t exist on my Jetson Xavier AGX. That implies that if I move from one Jetson to another, i.e. development board to one from another vendor, that these paths may be different.

My temporary fix is to have my telemetry process fork, launch tegrastats with execl, pipe the output to my process, then kill the tegrastats process with a signal SIGINT. Another issues is that tegrastats seems to have a delay between being invoked and outputting the results as if the wait defined by the interval parameter is applied prior to the first output being written. (I can’t tell since I can’t find the source code.) This makes it very hard to get telemetry at specific moments in time. Again, this may all be moot, but the documentation is lacking and extremely vague.

What would be the best way to get the tegrastats telemetry while relying on clearly documented behavior which is reliable across multiple Jetson Xavier AGX boards from various vendors?

hello rtrahan504,

it’s /sys/bus/i2c/drivers/ina3221x/1-0040/iio:device0/in_voltage0_input for Jetson AGX Xavier.
suggest you should refer to developer guide, Power Management for Jetson Xavier NX and Jetson AGX Xavier Series Devices.
if you check the Software-Based Power Consumption Modeling session, you’ll see different path for Jetson Xavier NX and Jetson AGX Xavier series for INA3221 power monitors.

One very simple method (at least from command line) is to pipe it through “head -n 1”. Example:
tegrastats | head -n 1"

1 Like

Thanks. I’ll mark this as the answer since it specifically answers my original question. I didn’t realize head would actually terminate the tegrastats process after 1 line. Nice!

This isn’t actually the solution I went with since tegrastats requires root permissions for some fields. Instead I created a service which runs as root and makes the information available to other non-root processes.

It would still be nice if Nvidia would provide an API like SMI so that none of these command line hacks are needed. This would be especially nice so that I would more easily know at compile time if the program is well formed when moving between various hardware versions.

The above cannot be done since SMI depends on a PCI device. The Jetson GPU is tied directly to the memory controller and does not use PCI.

The reason for using root to access this is because it is simply reading files from “/sys”, and many of those have permissions of being readable only by user root. Since those are not “real” files, but really the result of a driver, I don’t think there is a simple way to make that content readable by non-root.