I recently have been experimenting with a Jetson Orin Nano 8GB Developer Kit, with the goal of running it with the lowest possible power consumption in an effort to maximize the battery life of our system.
For some context, our system will perform an inference on the GPU and execute other CPU instructions once per second. Because of this, S2RAM mode is not likely to be useful, as the overhead for entering/exiting the state adds too much latency to be able to run our system once per second.
Boot from MicroSD (as NVMe takes significantly more power)
Boot with PCIe powersave mode
Removed Wifi Chip (eventually won’t matter as I disable PCIe)
Custom Low Power nvpmodel configuration
2 CPU Cores on
Low CPU Frequency
Low GPU Frequency
Low eMC frequency
Disabled the following in the device tree:
Vi0
Vi1
display
dce
sound
hda
isp
nvcsi
Change minimum residency from 30ms to 10ms (to enter cpu idle state more frequently
Disable pcie driver (pcie_tegra194)
With all of these modifications, I am able to achieve the following power measurements:
Entire Jetson Carrier Board (measured with Joulescope): 2.6 W
Tegrastats:
VDD_IN: 2180 mW
VDD_CPU_GPU_CV: 370 mW (both CPU and GPU are roughtly 0% load)
VDD_SOC: 945 mW
It appears from these measurements that outside of the CPU/GPU, there is roughly 1.8W unaccounted for on the Tegra Chip (not including carrier board components). The CPU/GPU loads are nearly 0.
When I put the device into S2RAM mode, I can get the idle power down to ~300mW, but like I said above - this mode likely is not useful for our system’s intended use case.
Are there any other optimizations that I can make to my system that I have not done already? I feel that I have covered most of the strategies outlined in the Nvidia Developer Guide, and so I was wondering what could be accounting for the power consumption remaining on the Jetson/if there are any ways to reduce the power consumption even further.
VDD_SOC power consumption should be included in you calculation. Most of the IO and IP blocks are in this power domain. With this included the difference would halve from the unaccounted figure you have quoted. There would be some onboard regulator efficiency losses.
My understanding is that a rough breakdown of power consumption is as follows:
Total Power Supplied to Carrier Board: 2600 mW
Carrier Board Components: 400 mW
VDD_IN: 2200 mW
VDD_CPU_GPU_CV: 370 mW
VDD_SOC: 945 mW
Unknown: ~900 mW
Is this an accurate breakdown for this particular system?
Regarding the VDD_SOC power draw, is there a pathway to reduce power consumption by altering the IO/IP blocks in any way? I.e. other device tree nodes / drivers that can be disabled?
In terms of the unaccounted for ~900 mW, would the entirety of it be resulting from regulator efficiency losses on the SOC itself? Is there any possibility of disabling regulators (perhaps if any are not being used?). Could there be other sources contributing to the quiescent power on the SOC? It seems like 900 mA is a lot of power to be contributed to efficiency losses.
Another possibility that is being considered is using a 4GB RAM version of the Orin Nano instead of the 8GB RAM version - would you expect this to contribute to significant power savings?
What is the DRAM frequency of operation? DRAM power would be a significant chunk at such low total module power levels. DRAM size may not make much difference, but the frequency would. Unused IP blocks could be disabled/power gated, if not used.
Does the EMC frequency that is set in nvpmodel.conf correspond to the DRAM frequency (or is that what you are referring to?). EMC is set to 2133 MHz on the current system.
Also, is the best place to track down a list of the IO/IP blocks the Orin Nano TRM?
In terms of reducing power of unused IP blocks, is it sufficient to set their status to disabled in a device tree overlay? Or are there other steps required to minimize/eliminate power from those blocks?
So far I have the following blocks disabled in the device tree:
PVA
DLA
CSI
ISP
NVDEC
NVENC
OFA
DMIC(1-4)
Ethernet
USB
However, the power consumption has not changed noticeably. If all that is necessary is disabling within the device tree source file, perhaps this is due to these device tree blocks already being power-gated or in a very low-powered idle state when not being used.
Are these devices still drawing power when not being used? Is there a way to remove them from the VDD_CORE power rail completely (potentially from a bpmp configuration)? Or is this not possible / it wouldn’t make a difference?
Yes, however the overhead of entering and exiting SC7 was around 3-4 seconds total, which is too much latency for our use case. We are aiming for an operating frequency of around 1 operation every 1-2 seconds.
It might become a more viable option if there were ways to optimize this overhead and reduce the time required to enter/exit this mode
We are also trying to minimize idle power consumption. Reducing memory controller clock appears to save 500 mW. See Clocks — NVIDIA Jetson Linux Developer Guide for straightforward instructions on manually setting EMC clock via sysfs.
$ cat /sys/kernel/debug/bpmp/debug/emc/possible_rates
204000 665600 2133000
I’m not sure yet, but I think something in the default configuration is keeping the EMC pegged at 2133MHz. Setting it to 204Mhz saves ~500mW for us but we’re currently above 4 watts.
I also tried setting everything in /sys/class/devfreq (vic, nvjpg, nvdec, ofa) to their respective minimum frequencies but it had no effect on power consumption.
I think it would save the community a lot of time if there was a doc/post with fine-grained power consumption information. @hsmith did you notice any changes in particular that contributed a lot to your power saving?
according to my experience, it is around 4W of idle power consumption.
please dig into tegrastats reports, you may refer to VDD_IN for current power consumption.
besides.. what’s the thermal condition?
Proper cooling is not only helpful for idle power optimization but the overall power and performance, please also give it a try to keep the Tj at 40C.
it also look expected.
please note that, you should also disable gdm3 to reduce some time for entering/exiting deep-sleep.
for instance, $ sudo systemctl stop gdm $ sudo loginctl terminate-seat seat0
besides.. may I know how you enter suspend?
please test below with the command for entering SC7. (i.e. by using sysfs control.) $ sudo -i # echo deep > /sys/power/mem_sleep # echo mem > /sys/power/state
Some noteworthy device tree modifications included disabling the audio devices (for instance, sudo modprobe -r snd_hda_tegra saves a non-trivial amount of power) and camera devices.
Our final Jetson with these modifications idles at about 2.6 W supplied to the entire carrier board, and 2.1 W according to TegraStats.
Of course, these changes assume that you do not need the PCIe bus (which includes access to the WiFi chip included with the DevKit, which is a PCIe device). If you need access to the WiFi chip, then you are going to need more power.
I had toyed with the EMC frequency, however I did not notice a significant change in power draw by dropping the frequency from 2133 KHz to 204 KHz. Perhaps this is because in my idle state, I am not accessing enough memory to make a difference.
I had a similar experience with the frequency tuning of modules such as vic, nvjpg, nvdec, ofa, etc. My guess is that they are already well power-gated, and so as long as they are not in use, modifying them or turning them off will not make much of a difference in terms of power draw. Kudos to the Nvidia engineers if this is the case.
If you or anyone else noticed a change not included here that made a noticeable impact on the power consumption, it would be very helpful to hear about.
For context, I have a python script that is repeatedly running a model on the GPU, and then sleeping in SC7 in between each inference.
When I use repeated calls to SC7 with echo mem > /sys/power/state after having set a wakeup time with echo +5 > /sys/class/rtc/rtc0/wakealarm in my python script, I eventually hang at the following point on my debug UART console: