Is it normal to have power usage increase when your UPS switches over to battery?
I was monitoring while testing out trying to safely shut down my 3 node Proxmox cluster and Truenas Scale in my home lab that are all connected to the same Tripp Lite UPS before testing I noticed that the UPS says I should have about 15 minutes of runtime with a 36% load but as soon as the plug is pulled from the wall it starts saying that it has 100% load and the runtime dropped to about 4-5 minutes. When I looked at the reporting tab in Truenas it shows that the CPU temps are increasing rapidly but does not show an increase in CPU usage so I was confused as to what would be causing this.
I was also wondering why the reporting tab for UPS shows runtime in days rather than either hours or minutes or better yet auto scale
Is everything shutting down and is that causing increased power draw?
Could it be that the battery of the UPS isn’t the best, anymore, and that the voltage drops too much under load and, therefore, the remaining runtime decreases, as the UPS detects a decrease of the battery voltage?
This could be - at least - the reason for the lower runtime. Why the UPS reports a higher load…maybe an issue with the implementation of the UPS. Maybe, it does some calculations about the load and uses the estimated remaining battery capacity in the formula 
I don’t think that the load really increases in your case.
1 Like
Bad SLA (sealed lead acid) batteries behave like that. How old are the batteries?
Batteries are likely part of it but like PSUs, UPS’ have a sweet spot re: generating power. Deviate beyond and the efficiency of the DC-AC inverter goes in the toilet and with it, runtime.
Run a raspberry pi on a wall wart from an UPS and see what happens, the runtime isn’t days as one would expect.
This is the reason I’m looking into DC-DC UPSs since MikroTik, etc all run on wide-input DC. That cuts out the very inefficient DC-AC, AC-DC middleman.
@dan has done some very interesting work with LiFePo retrofits, I may use similar cells to eventually power my DC gear here with some parts from pico-box for control & transfer, etc. That should give oodles of runtime.
2 Likes
This is happening the instant I pull the power cord so it seems like there is something happening on the host.
The UPS is a Tripp Lite 1500LCDXL that was purchased new in March 2023
The settings on the UPS service are
UPS goes on battery
shutdown timer : 240
shutdown command: /sbin/shutdown -P
Power off UPS unchecked
Supermicro X11SPL-F Motherboard With Intel Xeon Gold 6148 CPU 2.4GHz
45 Drives Storinator Hybrid F8X2 enclosure
That’s really interesting behaviour. I’d get on the console and run htop to see what processes are hammering the CPU when you switch to battery. You should not see increased CPU temps without an accompanying increase in load, that’s just physics.
Looking at the docs, it seems the default behaviour for TrueNAS when configured to use a UPS is to shutdown as soon as it switches to battery. As @SmallBarky suggested, if you have a lot of VMs or containers running this could put significantly increased load on your system.
You mentioned that you have other systems connected to the UPS. Are they all in communication with the UPS somehow? Do they all know that the UPS is on battery and start running some shutdown scripts, or is it just your Scale box? Are you using networkupstools on the other hosts, and is the Scale box the Master?
yes the other 3 Proxmox nodes are using nut-client looking at the TrueNAS for communication to the UPS to start shutting down when the UPS switches to battery. That is the reason I would like the delay in shutting down so that al the VMs on Proxmox have time to finish writes to NFS and then shutdown. Off to work now so will look at htop tonight when I get home.
The Proxmox nodes are NUC 13 gen Pros so should not be pulling a heavy load from ups either. And I thought the comms between them and the TrueNAS box would be pretty continuous but maybe that is what is causing it
1 Like
It could be all the activity associated with a graceful shutdown.
1 Like
I’ve run into this in the past with old APC and some newer systems as well. I’ve heard a few explanations for this and the one I think is the most accurate is this: Most UPSs are calculating based off current throughput and estimated battery health. This can be deceiving in a way because most UPSs are sending AC current through directly during normal operations and are calculating based on that metric. However, when main power is lost, the UPS must now convert from the DC battery to AC. This conversion is not 100% efficient and greater current must be drawn from the battery to meet the requirements of the devices plugged into the UPS.
That could also be complete BS but it seems to make sense to me. I’ve not seen this on any double conversion UPSs.
Line-interactive UPSs (especially consumer grade ones), from all vendors I’ve seen, TrippLite, APC, Eaton, CyberPower, etc…Generally suck at:
- Estimating run time when they are in “normal” AC operating mode
- Generating a “real” sine-wave, despite the marketing, further reducing inefficiency
- Giving you any realistic indicator of battery health
Plus:
This is correct.
@fonze98 You are comparing Apples/Oranges. You’d want to disable the Auto-Shutdown/UPS driver thing in TrueNAS to actually “see” the difference, and you shouldn’t see a difference from the CPU graph at all.
This is also true. But the pricing and availability of a double-online conversion 1500 or 2200 KVA units with standard NEMA 5-15p or 5-20P plugs makes them basically unobtanium for home use.
1 Like
nut seems a little weird here I shutdown the proxmox cluster so no communications happening from nut-client and started monitoring htop in TrueNAS. The first screencap is it running normally and the second is when it is on battery. It seems as though nut is a single threaded hog when the battery kicks on
Ok doing the same test with the settings on the UPS service of
UPS reaches low battery
shutdown timer : 0
shutdown command: /sbin/shutdown -P
Power off UPS unchecked
does not cause the service to use 100% of a core
Looks like it is a known bug and had a ticket for it that was closed with no changes.
https://ixsystems.atlassian.net/browse/NAS-126746
1 Like
Ah, that’s genius: power goes out, UPS kicks in, UPS monitoring software goes nuts (no pun intended), cranks up the CPU and drains the battery faster 
@kris, this seems like a really easy fix - i.e. incorporate version 2.8.1 of NUT and be done with this issue? Why was the ticket closed without resolution? FWIW, Dragonfish 24.04.2 is running NUT 2.8.0
In this case it’s a matter of what packages are distributed for debian bookworm IIRC 2.8.1 is Sid only.
2 Likes
I can fully understand why iX have a policy to use only Stable packages, hence why Nut is still at 2.8.0.
The issue here seems to me that Caleb closed the ticket by making an assumption that when packages were updated, Nut 2.8.1 would be included. (I assume that he didn’t check.)
And the resolution seems to me for iX either:
-
To make an exception and upgrade Nut to 2.8.1 despite it being SID status; or
-
To reopen NAS-126746 and wait for Debian to make 2.8.1 the stable release.
1 Like
Sorry, I got busy and forgot to follow up I opened a new ticket referencing the old one and I received a satisfactory resolution for me. [NAS-130175] - iXsystems TrueNAS Jira
Hi all - I know the resolution of this depends on an update on the Debian repo side but am wondering if this issue is now fixed in Scale 24.10?
I have a test Scale box where I could upgrade but I wouldn’t even know where to start looking since I can’t run apt or dpkg commands…
