Is this possible in Linux?

[Gat Pelsinger]

I am adding a lot of stuff to my i3bar and I am not proud of how many CPU cycles they are talking. But having my display brightness monitor only update 30 seconds later after I change it would be very uncool. Like a very normal optimization method (which probably even Windows does), is it possible to instead of checking maybe like a file that updates every interval, we do such that when the file updates or a program or a bash script is run, it queries our monitor in our i3 bar to update.

 

This won't work on all the monitoring daemons like CPU and memory monitors which require updating continuously, but stuff like time (unless displaying seconds), brightness, battery power, internet icon (ethernet or wifi), volume, all those don't need to update every second, but if made to update after a long time would feel weird. Instead, can we not make that if whatever they are made to watch gets updated, they would query the monitor daemons to update. Of course, we won't create another daemon keeping a watch on the source and updating it frequently, but instead updating the source itself (ok, it's not possible) to after doing whatever action it was supposed to do (like lowering the screen brightness), it will query its specified daemon to update.

[wasab]

Not sure what you are asking here but you have no control over when and how often your battery indicator updates itself unless there is actually a config file that allow you to do so. 

 

Learn crontab if you are looking to run specific command at a set interval. 

[Gat Pelsinger]

12 minutes ago, wasab said:

but you have no control over when and how often your battery indicator updates itself unless there is actually a config file that allow you to do so.

 

There's no need for that. Whenever the code or anything in the OS updates the battery percentage because it changed, we also make it give a signal to our daemon to update the monitoring. But yeah, I think it is quite impossible to do so.

 

Actually, is there something similar to task scheduler in Linux? With that, if it has an entry to which it updates the battery percentage, then we can make it update our daemon as well.

[Eigenvektor]

22 minutes ago, Gat Pelsinger said:

Actually, is there something similar to task scheduler in Linux?

There's cron, which allows you to schedule tasks at specific times or intervals. It doesn't do anything for/with battery level. What you could do is run a script every minute or so, then have that react to changes in battery level.

 

Whatever widget you use that shows the battery percentage is going to do that on its own, it isn't going to rely on an external task scheduler.

[Gat Pelsinger]

@Eigenvektor

 

Yah but that's the same problem. Either update it every second at the cost of CPU cycles or update it less frequently and have to wait to see the changes after the action has been performed.

[Eigenvektor]

1 minute ago, Gat Pelsinger said:

after the action has been performed.

What do you mean by action in this context? Do you want to react to battery level changes or someone plugging in power or similar?

 

You could probably solve the issue programmatically, I'm certain there's some system level events for that kind of stuff.

[wasab]

Curious, why do you care so much about how many cpu cycles these things run? Gui runs cpu cycle. Web browsing runs cpu cycle. You bad at typing and need to use backspace on a keyboard often means more cpu cycles. Question is who cares? Your computer can handle it so why wouldn't you have these softwares use up more cpu cycles? 

 

If like say, you have a super powerful graphics card that can run games at 4k, wouldnt you want to crank resolution up to 4k when gaming? Are you going to lower the resolution and settings of your games to 360p and minimum because these means less gpu cycle?

 

This is why I always roll my eyes at people who install a minimum desktop enviorment for Linux even though their machines rock a super high end rtx 4080 and up with 32gb+ ram. 

 

Cpu, same thing. Ram, same. These sounds just like a waste of your expensive hardware capacity and you doing extra work for a net loss. 

[Gat Pelsinger]

@wasab

 

I have a laptop and idling matters. CPU power is significantly higher when running these things. The second thing is I can "feel" my kernel suffocating reacting to syscalls every second. Not what I really mean but I think you get it, probably. Causing such interrupts every second actually does hammer performance a little bit (especially when CPU bound).

[Gat Pelsinger]

@Eigenvektor

 

Bro, it's simple!

 

What happens -

Battery discharging. Percentage got less. Kernel reports in ACPI. My daemon polling every second catches the change. Daemon updates the percentage on the screen.

 

What I want -

Battery discharging. Percentage got less. Kernel reports in ACPI. Something magically gives signal to my idle daemon. Daemon updates the percentage on the screen.

[wasab]

20 hours ago, Gat Pelsinger said:

@wasab

 

I have a laptop and idling matters. CPU power is significantly higher when running these things. The second thing is I can "feel" my kernel suffocating reacting to syscalls every second. Not what I really mean but I think you get it, probably. Causing such interrupts every second actually does hammer performance a little bit (especially when CPU bound).

if you are worry about battery life, let me tell you....

 

99% battery longevity comes from lowering screen brightness, reducing cpu frequency(aka lowering performance) and closing down power hungry applications like games/constant web browsing. this is what your phone's battery savings mode does as matter of fact. 

 

probably less than 1% comes from everything you are trying to do above.

 

leaving your computer powered on and never turning it off also drains battery and costs cpu cycle do you know? have you ever consider just turning your computer off/putting it to sleep when idling? 

 

lastly, i dont know how your kernel suffocates. they are 1s and 0s and exist as some data on a hardrive which manifests physically in the real world as just some magnetic state if you use magnetic drive or as some resistors that allow or stops eletricity if you are talking about ssd. so your kernel does absolutely zero work since it is literally just data represented by magnets and transistors arrange in certain way to represent 1s and 0s in the real physical universe. 

 

rather your cpu does any "actual work" since it reads those instructions and executes them and this "work" manifests itself in the real physical universe as just how much and how often eletricity runs through its semiconductor circuits. For all intents and purposes, my eletric kettle probably does more joules of work and "suffocates" more than your laptop considering it literally needs more electrons flowing through its wire to boil a liter of water vs the whatever is needed for your laptop to run its kernel and operating system. 

[Sauron]

10 hours ago, Gat Pelsinger said:

The second thing is I can "feel" my kernel suffocating reacting to syscalls every second.

No, you can't. I assure you polling ACPI information even once per second is not going to significantly stress a modern cpu. You can check this yourself with htop or any other program that reports live cpu usage.

10 hours ago, Gat Pelsinger said:

Battery discharging. Percentage got less. Kernel reports in ACPI. Something magically gives signal to my idle daemon. Daemon updates the percentage on the screen.

something like this? https://wiki.archlinux.org/title/Acpid

 

you'll have to check yourself whether your laptop generates an event for the percentage changing... I wouldn't count on it, considering 30s or even 1 minute is a perfectly adequate refresh rate for battery level... I mean, if you're worried about your percentage changing much faster than that then you should replace your battery.

[Eigenvektor]

Quote

Battery discharging. Percentage got less. Kernel reports in ACPI. My daemon polling every second catches the change. Daemon updates the percentage on the screen.

As I said above, there is likely some kernel level power event you can subscribe to.

 

Otherwise, I would suggest a slightly more conservative approach. The battery percentage is unlikely to change significantly in 1 second.

 

When the app starts, query battery percentage and projected battery life. Use that to estimate when the battery will next go down by 1%.

 

Use that estimation to determine when you should query again.

 

When you query, check the expected delta vs the actual delta, use that to adjust your poll rate accordingly.

 

Do all of that in a low priority background thread. Only update the UI when percentage has actually changed.

[10leej]

18 hours ago, Gat Pelsinger said:

I am adding a lot of stuff to my i3bar and I am not proud of how many CPU cycles they are talking. But having my display brightness monitor only update 30 seconds later after I change it would be very uncool. Like a very normal optimization method (which probably even Windows does), is it possible to instead of checking maybe like a file that updates every interval, we do such that when the file updates or a program or a bash script is run, it queries our monitor in our i3 bar to update.

 

This won't work on all the monitoring daemons like CPU and memory monitors which require updating continuously, but stuff like time (unless displaying seconds), brightness, battery power, internet icon (ethernet or wifi), volume, all those don't need to update every second, but if made to update after a long time would feel weird. Instead, can we not make that if whatever they are made to watch gets updated, they would query the monitor daemons to update. Of course, we won't create another daemon keeping a watch on the source and updating it frequently, but instead updating the source itself (ok, it's not possible) to after doing whatever action it was supposed to do (like lowering the screen brightness), it will query its specified daemon to update.

i3blocks or delve into the realm of bash scripting

[thevictor390]

15 hours ago, Gat Pelsinger said:

@wasab

 

I have a laptop and idling matters. CPU power is significantly higher when running these things. The second thing is I can "feel" my kernel suffocating reacting to syscalls every second. Not what I really mean but I think you get it, probably. Causing such interrupts every second actually does hammer performance a little bit (especially when CPU bound).

At a certain point, you can consider that your laptop runs multiple billions of "cycles" per second. Billion with a B. And compare that to the amount of effort you are spending to save a few of them. Your body also spends energy for every action you take. And we are splitting hairs over billionths of seconds.