I had a Jetson Orin Nano 8GB running jetpack 5.2. I’m trying to drop the power usage for running on batteries. I have connected a power meter between the adapter and the jetson. When I login and set the power mode with the GUI to 7W and then reboot. I login and I can see on the power meter that it’s working.
However, if I stop the GUI with
sudo systemctl stop gdm3.service
Then the power shoots up again. The same applies if I disable the graphical login. There’s clearly some dependency on the GUI login for the power mode to work. Running
nvpmodel -q
Shows the mode to be 7W but the power meter shows it’s running at greater than 10W if the GUI is not running.
Clearly running a graphical user login is going to use more power than not. Running on batteries it’s desirable not to have to run the GUI. But the above shows there’s clearly a dependency.
How can I run on 7W power mode headless and have it really work ?
Regards,
Hi KimHendrikse,
We don’t have Jetpack 5.2. Do you mean Jetpack 5.1.2(R35.4.1)?
Are you using the custom carrier board for Orin Nano since we don’t have batteries on the devkit board?
It might be expected since it needs more power for the display.
Is this your use case to use 7W power mode w/o GUI?
Yes, I mean 5.1.2.
I will have to make a power source that delivers power to the same sort of plug
It uses more power so I will want to eliminate it. Running on batteries I need all of the advantages I can get.
Yes., the use case is without GUI, it’s for a wildlife related use case and there will be no screen, it will be running outside on solar power. Every ounce of power I can get rid off is useful. As it is, it’s very challenging but the end result will be very nice indeed.
It looks like I can save an additional 0.6W power if I can disable the GUI. It’s for a human wildlife conflict mitigation project (Bear and lynx initially) and needs to stay outside for long periods of time.
This is the tegrastats when the GUI is running:
09-30-2024 18:48:09 RAM 667/7471MB (lfb 1583x4MB) SWAP 0/10240MB (cached 0MB) CPU [0%@960 ,0%@960 ,0%@960 ,0%@960 ,off,off] EMC_FREQ 0%@2133 GR3D_FREQ 0%@[407,0] VIC_FREQ 435 APE 200 CV0@-256C CPU@50.687C iwlwifi@41C SOC2@49.468C SOC0@48.687C CV1@-256C GPU@50C tj@50.812C SOC1@50.812C CV2@-256C VDD_IN 5291mW/5291mW VDD_CPU_GPU_CV 406mW/406mW VDD_SOC 1625mW/1625mW
This is tegastats when it is not
09-30-2024 18:49:47 RAM 366/7471MB (lfb 1697x4MB) SWAP 0/10240MB (cached 0MB) CPU [0%@729 ,0%@729 ,0%@729 ,0%@729 ,off,off] EMC_FREQ 0%@2133 GR3D_FREQ 0%@[305,0] VIC_FREQ 435 APE 200 CV0@-256C CPU@52.062C iwlwifi@41C SOC2@50.468C SOC0@49.906C CV1@-256C GPU@50.718C tj@52.312C SOC1@52.312C CV2@-256C VDD_IN 7030mW/7030mW VDD_CPU_GPU_CV 405mW/405mW VDD_SOC 3489mW/3489mW
VDD_SOC is 1625mW when the GUI is running and 3489mW when it is not. Much higher.
Maybe you can try with Minimal Flavor Root File System
Please share the result of the following command on your board.
# nvpmodel -q --verbose
and also, the /etc/nvpmodel.conf on your board for further check.
Hmm, it’s quite undesirable to change the whole development environment to try and get low power mode to work headless. I’m been running headless since 2019 and many models. Just not tried low power mode before. I do have to point out, that it is a Seeed Studio board, though I can’t see that making a difference, the kernel is identical and if we are talking about headless then the carrier specific component is not enabled.
I do also have a Jetson Nano Developer kit and a Xavier AGX Orin board, but haven’t tried it on these boards as they are not the ones that will be shipping.
The output of ```
NVPM VERB: Config file: /etc/nvpmodel.conf
And actually quite surprised that this seems to be a new question, surely robot maker’s etc must also want to run in low power mode and headless??
Regards
Okay, if you are using a custom carrier board which is not designed by you, then do not modify the rootfs.
It seems your power mode is working as expected now.
The power mode usage and headless mode are strongly depending on the requirement.
This is exactly my point. It “seems” to be working now based on the output and the command that I run but it is in fact not working. Measuring it with a power meter (that is between the ac adapter and the wall socket) shows that despite the output of the nvpmodel command the power usage jumped right up. This is also reflected in the output of the tegrastats that I showed earlier, which shows that VCC_SOC more than doubled.
That’s what’s so puzzeling.
My use case is outdoor battery operation for monitoring animals. I think it’s a use case that no one has done yet with jetsons but one which can be extremely valuable for biodiversity research as well as mitigating people/wildlife conflict.
This confuses me. How does modifying rootfs come into the picture?
Ah okay, you are suggesting that I do not modify the linux startup? Stopping GUI startup is a pretty normal thing to be able to do on linuxes that have been installed as a desktop.
Everything about it works just fine, just not this low power mode and there’s nothing to suggest that low power mode will work if I install the custom rootfs either at this stage.
That’s a pretty big hammer that would change everything else that my software stack depends on potentially. That link make’s no specific statement about low power mode still working and it’s not logical to assume that if nvpmodel says that the device is in low power mode and it in reality is not that it would relate to not using a GUI-less version.
But okay. It’s nice to know there is one of those. But it would change everything about my software installation procedure. Not something I can try right now especially as there’s no logic that this would fix the problem as I see it.
rootfs is tied to the design and execution of init during startup. init is systemd on Ubuntu, and the rootfs more or less designs the steps which systemd goes through to configure.
Linuxdev had the good suggestion to check dmesg when I shutdown the graphical login, thanks for that and I see that the kernel throws an exception:
Oct 4 17:28:26 kim-orin-nano-8g kernel: [268722.579163] ------------[ cut here ]------------#1 #1 #1 #1 #1
So this might be related to it.
However, I saw that exception in the logs already before I shutdown the graphical login I might add.
I’ll try again with Jetpack 6.*. It’s my intention to launch with that version anyway, I just haven’t ported everthing to it yet.
Kim
Okay, please also verify with Jetpack 6.1 (R36.4.0 ), which is just released last week.
1 Like
system
November 6, 2024, 5:22am
17
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.