A deeper insight into frequencies, voltages & a thermal script


Askarus

Forum Addict!
Joined
Sep 28, 2011
Messages
4,998
Location
Germany
This thread will be dedicated to my own experimental device tree tweaks in regards to voltage and frequency. It is based on the fantastic work that you can find here: 20*C Cooler, and now with water resistance!
I decided to make a new thread so that my files will not get lost in a huge pile of posts and I have a place where I can keep all my observations in one place.

CAUTION: Everything that is deemed as "stable" is the be treated as "stable enough" for me to run my Pyra, use it for web browsing and Discord.
@hns , this is a comprehension of all the things I figured out during the last days in regards to frequencies.

Prelude
This all starts with the work of @Asaggynoodle. What he did was to add frequencies to our existing ones.
What we currently have are steps of 250MHz, starting at 250MHz, reaching up to 1500MHz.

Those are our values:
Code:
   Hz        uV
 250000  750000
 500000  850000
 750000  950000
1000000 1050000
1250000 1100000
1500000 1250000

What @Asaggynoodle did, was to add frequencies in between our ones and interpolate the voltages accordingly.
This apparently led to a cooler and stable system to him.
Further, he unlocked frequencies beyond 1500MHz, up to 2GHz.

Tweaked values by Asaggynoodle:
Code:
   Hz        uV
 250000  750000
 375000  800000
 500000  850000
 625000  900000
 750000  950000
 875000 1000000
1000000 1050000
1125000 1075000
1250000 1100000
1400000 1200000
1500000 1250000
1600000 1300000
1700000 1350000
1800000 1350000
1900000 1350000
2000000 1450000

To unlock the frequencies above 1.5GHz, a modification to pyra-thermal.sh was required.
The original post and files can be found here.

As a realistic estimate, you will not be able to run your Pyra at 2GHz. I was able to use this device tree with unlocked 1.9GHz, however my Pyra overheated after a while of web browsing and clocked down to 250MHz in order to cool down.
In the end (after a while, to be fair) it froze. Either because it overheated, or because it simply is not stable at 1.9GHz.
However, limiting the clocks to 1.8GHz seemed to be quite a stable experience for me, despite my Pyra getting super warm (spoiler alert, I have a nice fix for this).


Hunting the floor - A lot of work, success and a big disappointment

Here is the idea
  1. Disable all frequencies except the single one I want to tweak
  2. Figure out the lowest possible number at which my Pyra boots
  3. Do a full boot/login cycle with only that one frequency enabled
  4. If that succeeds without a freeze, that value is considered "stable enough"
  5. Do this test for 10 Pyras in total
  6. If one Pyra fails, increase the voltage by 10mV
  7. If all Pyras make it through the boot/login/shutdown cycle without freeze, consider that frequency-voltage combination "stable enough"
  8. Disable that one frequency and test the next one, do this for all of Asaggynoodle's frequencies.
The idea was that such a testing would provide me the absolute minimum values required for each frequency to run my Pyra.
I expected crashes along the way and if those occur, the plan was to gradually increase the voltages.
(This alone took me the while Saturday and a bit of Sunday.)

Those are the results.
Absolute minimum voltages for each frequency to boot 10 Pyras reliably, if only one frequency is being used in isolation:
Code:
&cpu0 {
    operating-points = <
        /* kHz    uV */
         250000  670000
         375000  730000
         500000  770000
         625000  770000
         750000  810000
         875000  860000
        1000000  920000
        1125000  960000
        1250000 1010000
        1400000 1080000
        1500000 1130000
    >;
};
(See attachment: CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip)

As you can see, I could reduce the voltages by quite a bit for each frequency.
This gave me hope that even if I had to increase them a bit for stability reasons, the effort was worth it.

Aaaaand it did not work. Even though each of the frequencies run stable in isolation, as soon as they are being combined, things get completely unstable and no Pyra would boot.
So yeah, that was disappointing, a lot of work for no gains.

Further I found out that at 250 MHz running at 670mV does not provide substantially (probably nothing at all) more battery life compared to running 250MHz at 77mV.

I compiled the files in a device tree, jsut in case someone is brave and wants to test it. See file: CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip

There is no giving up - Success after all

I put so much work into it, I did not allow it to be all for nothing. So the next logical thing to do is to put even more work into it.

I did what most scientists do, random poking around. I increased all voltages gradually, increased them individually but it all seemed to not be of much use.
However, one thing helped: Disabling 250MHz.

That was suspicious. I investigated this further and found out that it was the lower end that caused troubles.
Even if 250MHz can run below 700mV in isolation, it fails immediately if I add more frequencies at the lower end.
So I began increasing the voltages at the lower end and viola, my Pyra survived a boot cycle.
Not just that. It was stable if I used it for more than just a boot.

It is super interesting, by how much I had to increase the voltages at the lower end. Anything below 750mV (its default value) caused immediate crashes.

Stable values with tweaked voltages, 125MHz steps:
Code:
&cpu0 {
    operating-points = <
        /* kHz    uV */
         250000  750000
         375000  750000
         500000  770000
         625000  770000
         750000  810000
         875000  860000
        1000000  920000
        1125000  960000
        1250000 1010000
        1400000 1080000
        1500000 1130000
        1600000 1190000
        1700000 1240000
        1800000 1300000
    >;
};
(See attachment: STABLE_step-125_start-250_end-1800.zip)

Those values should be save to use. There might be some crashes after a while, so keep a backup of your original device tree and test it on a boot SD card first.
If you Pyra boots, it should be save for a long term test.

On a positive note, pretty much all frequencies above 375MHz could keep their optimized values.


More experimentation, more frequencies

As a wise man (HNS) just told me:
Does it hurt: well, unnecessary complexity with marginal benefit may sometimes hurt :)

Luckily I was faster and there was no force to stop my free flowing thoughts.
Why stick with 125MHz steps, if you can have 50MHz?

What I did was to use the power of interpolation and guessing to take the results from above and apply the tweaked voltages to 50MHz steps.
Aaaand it did not work. Of course it did not.
However the issue once again was the lower end and handling the lower frequencies a bit more conservatively solved the issue.
A bit more experimentation and using conservative values for the interpolated and guessed values gave me quite stable results.

Stable values with tweaked voltages, 50MHz steps:
Code:
&cpu0 {
    operating-points = <
        /* kHz    uV */
         250000  750000
         300000  760000
         350000  770000
         400000  770000
         450000  770000
         500000  770000
         550000  770000
         600000  770000
         650000  780000
         700000  790000
         750000  810000
         800000  830000
         850000  850000
         900000  870000
         950000  900000
        1000000  920000
        1050000  940000
        1100000  960000
        1150000  970000
        1200000  990000
        1250000 1010000
        1300000 1030000
        1350000 1060000
        1400000 1080000
        1450000 1110000
        1500000 1130000
        1550000 1160000
        1600000 1190000
        1650000 1220000
        1700000 1250000
        1750000 1280000
        1800000 1300000
    >;
};
(See attachment: STABLE_step-50_start-250_end-1800.zip)


I have no idea if this does any good or just provides more complexity.
Setting the XFCE frequency monitor to 0.25s update interval at least shows me that pretty much all the frequencies are being used.
Only above 1.4 it's all or nothing, the steps below are being utilized.

More, all for science (More because more is better. If you disagree, why go on and read more? Got you with that one!)

@johnicboom :
What we really want is lower frequencies in order to save power

@EvilDragon at a later stage:
50Mhz is probably just fake, the chip can't go below 250MHz technically.

I was not really in a mood of experimenting more after I spent so much time getting this all to work.
Further I was the same opinion of EvilDragon and expected it all to not work.
However the first of the two persons helped me with LeTux, whereas the second one just pays me money.
I could not deny the first one, so I began experimenting with low frequencies.

Really low frequencies. We are talking 10 MHz here.
I started with 250MHz and went down in 50MHz steps, all the way down to 50MHz.
No boot.
Luckily I had some experience already: More frequencies at the lower end requires higher voltages.
Yes, it is absolutely non intuitive but I had to increase the voltages at 250MHz and below to get it all to a stable state.
It was just by 20mV, leading to 770mV.
So to make this clear, 250MHz boots stable at 670mV if used in isolation, requires 750mV if more frequencies, starting at 375MHz are being added and requires 77mV if frequencies below are being added.
Further, any frequency below 250MHz also requires 77mV or else the Pyra does not boot at all.

Stable values with tweaked voltages, 50MHz steps, starting at 50MHz:
Code:
&cpu0 {
    operating-points = <
        /* kHz    uV */
          50000  770000
         100000  770000
         150000  770000
         200000  770000
         250000  770000
         300000  770000
         350000  770000
         400000  770000
         450000  770000
         500000  770000
         550000  770000
         600000  770000
         650000  780000
         700000  790000
         750000  810000
         800000  830000
         850000  850000
         900000  870000
         950000  900000
        1000000  920000
        1050000  940000
        1100000  960000
        1150000  970000
        1200000  990000
        1250000 1010000
        1300000 1030000
        1350000 1060000
        1400000 1080000
        1450000 1110000
        1500000 1130000
        1550000 1160000
        1600000 1190000
        1650000 1220000
        1700000 1250000
        1750000 1280000
        1800000 1300000
    >;
};
(See attachment: STABLE_step-50_start-50_end-1800.zip)


Once again, using the XFCE frequency monitor panel applet and setting its update interval to 0.25s show that all values below 250MHz are being used in idle mode.
This is true when using the "ondemand" governor but even more, with my Pyra constantly running at 50MHz, when using the "conservative" governor.

Does this help idle battery life? No.
Still, it's satisfying watching my Pyra running at low frequencies.

Since yesterday I run those frequencies on my main private Pyra which I use a lot for browsing and Discord. Further I leave it on and on a charger all day to test stability at the lower end.
Until now it was all stable with just one freeze. The freeze happened under load and the frequency monitor showed 1.7GHz, so I increased the voltage for that frequency by 10mV (that is already included in the values above).
I expect more occasional freezes along the way and I probably will increase the voltage for each frequency by 10mV, just to be sure.
For now, I'll leave it as is an want to observe. My Pyra is reasonable stable with those values, way more stable than it was before aTc pushed the freeze fix for Bookworm.

Pleasenot a statement by @hns :
Well, this mixes up reommended (by TI) values and experimentatlly proven values "to work". The problem is that there is a "works sometimes" range between certainly good and certainly bad values. I think the 250 MHz is what TI has said as the minimum they guarantee. It may run slower but there is no guaranee. This has its basis in how CMOS and MOS circuits and transistors work. Some are designed for a minimum (and maximum) clock speed. And no manufacturer recommends to go below to stay on the safe side. If you go below you are unsafe but it may work for you. For the next 5 months and suddenly fail. But nobody knows...

So if you don't feel like experimenting and watching those low values, feel free to use one of the other device trees.

Even lower, even higher
So I tried to go even lower. Maybe we could get a fake sleep like we did on the Pandora by running 10MHZ.

Nope, that starts to mess up the graphics output and eventually freezes the system.
The lowest I could get to have a somewhat stable system was 40MHz. Everything below caused instabilities and messed up graphics during the boot terminal.
Maybe one could do something about it with increased voltages, however after all the testing I went through, I did not feel like investing more.
Further, it is important to ensure stability of the system with tweaked voltages between (50MHz) 250MHz and 1800MHz.

Why not go higher, up to 2GHz?
Check out the post by Asaggynoodle, he has some hefty cooling improvements made jsut to sustain 2GHz for a bit.
My Pyra was not super stable at 1.9GHz and probably yours won't be, either.
I want to eliminate cause of sudden freezes by too high clock speeds, so I decided to leave those frequencies out for now.
Come one, be happy with 300MHz extra.
Further, I wanted a frequency range, that could savely run on a stock Pyra without any advanced cooling solution.
And please don't forget, that I inbvested way too much into this already and I need a break and test the currently stable values.


The best of both worlds - high clocks and a cool system

There was one more iussue to solve: 1.8GHz is not sustainable.
It eats through your battery and more importantly, the cooling of the Pyra won't be able to handle it for long.
Sustained 1.8GHz will result in overheating, which results in hefty throttling and downclocking to 250MHz, or worse, system freeze.

Luckily we have a solution: pyra-thermal.sh

This is a neat little script that is being called now and so often to check the CPU's temperature and to regulate the frequencies.
By default, it is used to emergency throttle the system if it reaches above 90 degree Celsius.

A simple fix to the overheating issue is to gradually reduce the max frequencies depending on the core temperature.
I once again took the modified pyra-temerature.sh from Asaggynoodle as a base and added some frequencies:

Frequency curve implemented in pyra-thermal.sh :
Code:
#Check Core, from hottest to coldest
    if [ ${core_temp} -gt 99000 ]
    then
            setMaxFreq 250
    elif [ ${core_temp} -gt 97000 ]
    then
            setMaxFreq 500
    elif [ ${core_temp} -gt 95000 ]
    then
            setMaxFreq 750
    elif [ ${core_temp} -gt 93000 ]
    then
            setMaxFreq 1000
    elif [ ${core_temp} -gt 91000 ]
    then
            setMaxFreq 1250
    elif [ ${core_temp} -gt 85000 ]
    then
        setMaxFreq 1500
    elif [ ${core_temp} -gt 81000 ]
    then
        setMaxFreq 1600
    elif [ ${core_temp} -gt 76000 ]
    then
        setMaxFreq 1650
    elif [ ${core_temp} -gt 72000 ]
    then
        setMaxFreq 1700
    elif [ ${core_temp} -gt 68000 ]
    then
        setMaxFreq 1750
    fi

Everything above 85000 was already there.
The lower values represent a frequency curve that gradually reduces the maximum frequency depending on the current core temperature.

If the system is idle, we usually are below 68 degree Celsius and as aa result, we will clock up to 1.8GHz once we do anything demanding.
After not too long, we usually will clock down to 1.7GHz. That is usually sustained as max frequency pretty well during browsing or any regular use.
Lower values are only being used once we reach higher temps and do demanding stuff.

For me, that curve works wonderfully.
My Pyra stays cool and regulates itself while still allowing me to enjoy higher clocks most of the time.
I do not play games on my Pyra but I expect my thermal curve to be effective enought to clock down aggressively wnough to not overheat during gaming.
The hefty downclocking at 90 degree and above is part of the default OS, so if you games do not reach that level, they should also not reach it with my values.


Installation and tweaking

Attached to this post are multiple device tree files, compiled as dtb and in raw form as dts.
You only need the dts if you want to tweak them manually.
Also my modified pyra-thermal.sh script is attached.
If you do not want to overclock, you do not need my thermal script.

pyra-thermal.sh
In any case, it is save to use my thermal script, even if you do not want to overclock and set the value in line 8 to "1500".
Code:
maxFreq=1800
You do not need to modify any of the later values, that line defines the hard limit.

Frequency and voltage via device tree
Regarding device trees, pick one of the zip files, depending on which one you want to use.
Do NOT use the one what starts with CRASH. That is only for scientific purpose, if you want to have the respective values (see above).

Frequency Permanent conservative governor
Copy the file
Code:
cpufrequtils
into
Code:
/etc/default/cpufrequtils
.
On our system the prerequisites for that too work are already installed, so I consider it the best option.
The file only contains one line:
Code:
GOVERNOR="conservative"
Reboot to make the changes take effect.
If you want to switch back to "ondemand", simply delete the file again.
I am not sure if this has any positive effect.
At least it helps to keep the frequencies down.
It should not have any negative effect.

Installation path
Put the files into the following location:
Code:
/usr/share/pyra/scripts/pyra-thermal.sh
/boot/dtb/linux-image-5.6.19-daveiii-pyradef-aufs/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb

Installation path
To test your own frequencies, you need to make modifications to the divice three and compile it.
It is quite simple, here is how it's done:
Code:
apt-get install git build-essential flex bison libyaml-dev
git clone https://dev.pyra-handheld.com/packages/pyra-kernel    # or other repo
cd pyra-kernel
# git checkout <<branch>> # Use the default one for now
# modify arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dts    # or other files that have 'omap' or 'pyra' in their name
make pyra_defconfig dtbs
locate new dtb files in arch/arm/boot/dtb and copy to boot directory (ideally on a separate system on SD so you don't overwrite your working one)


What was it good for & what comes next

This all costed a lot of time and did not provide a huge boost in battery life.
In regards to idle, I maybe gained a few minutes if I use the 50MHz version.
It's probably not worth it, considering the comment made by hns.

What comes next
Regarding higher clock speeds, I could reduce the voltages by quite a bit for all, more than 100mV per step.
I did not do any long term tests in regards to battery life in day to day usage.
Maybe the added frequencies and lower voltages will result in less battery drain under common use scenarios.
That is something I will need to test during the next days while using my Pyra.
I do not plan any scientific load tests, however I am curious if I notice a difference (that is what matters, right).

Also we need a long term stability test for each frequency under a stress test.
Currently I do not feel like doing this, so if anyone wants to make a boot SD, boot my device tree with 50MHz steps and do a load test for each of them, feel welcomed to do so.
What I will do is to use my Pyra as much as I can with the fully unlocked 50MHz-1.8GHz devie tree and see if I run into any troubles.
If I do, I'll increase the voltages for each frequency by 10mV and that will probably solve the issue.
Remember, each of the frequencies (125MHz steps) already did a boot/log in/ shut down cycle test on 10 different Pyras.
So at least outliers should that refuse to boot should be taken into account.

I also did not check the heat in regards to the lower voltages.
So if one feels like doing a heat test, go ahead.

What was it good for
Even if we do not gain much increased battery life, we still gained an unlocked device tree up to 1.8GHz and a pyra-thermal.sh script that prevents overheating.
Feel free to use it, it should be pretty save, as long as the voltages are save.
Combined with the undervolting, maybe your Pyra will even run cooler than before.

Beyond frequency and voltage
In regards to idle battery life, what is more important than frequency and voltage, is tweaking the OS.
We should see what processes require the most background activity and identify those that we can disable.
Maybe we could disable USB, Bluetooth and other system components and services, like we did on the Pandora.
If we do so, a system tray launcher for quick access to enable them will probably be sufficient to conveniently provide access to those system components.
That however is a story for an other day and an other topic.

Good bye and good luck with the new device trees.
 

Attachments

  • CRASH_step_125_start_250_end_1500_minimumValuesSaveToBootInIsolation.zip
    17.8 KB · Views: 21
  • STABLE_step-50_start-50_end-1800.zip
    18 KB · Views: 31
  • STABLE_step-50_start-250_end-1800.zip
    18 KB · Views: 29
  • STABLE_step-125_start-250_end-1800.zip
    17.8 KB · Views: 30
  • pyra-thermal.sh.zip
    914 bytes · Views: 34
  • cpufrequtils.zip
    182 bytes · Views: 15
Last edited:
Great work and really deep and detailled documentation!

AFAIR, there is now some in-kernel mechanism which can throttle the CPU if some temperature zones are indicating "too hot". We never have tried/implemented anything there but it can replace the script you mentioned and potentially make it independent of user-space crashes. So it may be worth a look into.

Here is an example what I mean (at least they are discussing the same topics): https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3275/index.html#page/Tegra Linux Driver Package Development Guide/power_management_nano.html#wwpID0E0RJ0HA

PS: the effect you noticed on very low voltages with clock frequency changes may have these reasons: it is controlled by kernel software running on the same processor and current clock speed. I do not know if the clock frequency is increased first or the voltage (but it can be found out by looking into the source code). If clock is increased first, it may take too long for a slowly clocked processor to increase its own voltage and it gets stuck. Also, the voltage regulators need some time to settle on the new voltage.
 
Last edited:
AFAIR, there is now some in-kernel mechanism which can throttle the CPU if some temperature zones are indicating "too hot". We never have tried/implemented anything there but it can replace the script you mentioned and potentially make it independent of user-space crashes. So it may be worth a look into.

Here is an example what I mean (at least they are discussing the same topics): https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3275/index.html#page/Tegra Linux Driver Package Development Guide/power_management_nano.html#wwpID0E0RJ0HA
I understand that a kernel implementation has its advantages.
However, I like userspace because that allows for easy tweaking.
If the kernel exposes the frequency and temperature limits to the user and reads them from a file, that will be good enough I guess.

What governor do you recommend?
Personally I use conservative. At least it keeps the clocks lower while in idle and does not spike as quickly.
It should not make much of a difference but I still think that conservative is the way to go.
 
actually the governor is the most important. doesn't matter what frequencies are available if they aren't effectively selected.
 
In case you're like me, and wondering how to set your CPU governor permanently, I was able to do it by creating:
/etc/default/cpufrequtils

with this contents (mine didn't exist, so I modified the example from /usr/share/doc/cpufrequtils/examples):
ENABLE="true" GOVERNOR="conservative" MAX_SPEED=0 MIN_SPEED=0

If there's a better way, I'd love to know!

My Pyra is happy so far this morning, using the 50 MHz steps and the modified thermal script. Writing this message in Vivaldi, it's running from 50-700, mostly on the lower end.
 
Last edited:
In case you're like me, and wondering how to set your CPU governor permanently, I was able to do it by creating:
/etc/default/cpufrequtils

with this contents (mine didn't exist, so I modified the example from /usr/share/doc/cpufrequtils/examples):
ENABLE="false" GOVERNOR="conservative" MAX_SPEED=0 MIN_SPEED=0

If there's a better way, I'd love to know!

My Pyra is happy so far this morning, using the 50 MHz steps and the modified thermal script. Writing this message in Vivaldi, it's running from 50-700, mostly on the lower end.
Awesome, thank you for testing :)

Also thanks a lot for that information regarding the governor. I was wondering how to set it permanently but did not have time to look it up.

I left my Pyra powered on during the last few days. At least idle seems to be rock stable.
 
In case you're like me, and wondering how to set your CPU governor permanently, I was able to do it by creating:
/etc/default/cpufrequtils

with this contents (mine didn't exist, so I modified the example from /usr/share/doc/cpufrequtils/examples):
ENABLE="false" GOVERNOR="conservative" MAX_SPEED=0 MIN_SPEED=0

If there's a better way, I'd love to know!

My Pyra is happy so far this morning, using the 50 MHz steps and the modified thermal script. Writing this message in Vivaldi, it's running from 50-700, mostly on the lower end.

systemd exists. This works for me:

Code:
sudo nano /etc/systemd/system/conservativegovernor.service

Code:
  GNU nano 7.2                            /etc/systemd/system/conservativegovernor.service                                     
[Unit]
Description=Set CPU governor to conservative when on and to ondemand when off
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/bash -c 'echo conservative | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor'
ExecStop=/usr/bin/bash -c 'echo ondemand | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor'

[Install]
WantedBy=multi-user.target

Code:
sudo systemctl daemon-reload

sudo systemctl start conservativegovernor.service
sudo systemctl enable conservativegovernor.service
 
systemd exists. This works for me:
Oh, nice! I'll have to read up on why that's better than doing it with cpufrequtils, but I trust your judgement so undid my method and did with systemd.

I compiled box86 yesterday to test out something demanding. It didn't feel like the Pyra got too hot, but anonymoushindeiru's cpu-temp-speed.sh showed that core_thermal got up to 92 C. I didn't get a screenshot of that, but got close (this was a minute or so before compiling completed):
Compiling.png


Is it not following the expected frequency curve? Seems like it should have throttled down to 1250 MHz based on the core_thermal temp, right? It did throttle down from starting at 1.8 GHz, hung out at 1.7, then 1.6, before mostly settling down at 1.5 for the duration of the 20 minute or longer compilation time.
 
Oh, nice! I'll have to read up on why that's better than doing it with cpufrequtils, but I trust your judgement so undid my method and did with systemd.
It is mainly because systemd is on each system already. No idea if it is better. I just like to do whatever possible with systemd.
I have just never heard of cpufrequtils, so I wanted to offer an alternative. Might be better, might be worse.
 
Like I said, I don't know what is the best way to handle this.
Might very well be that cpufrequtils is the way to go.
 
I'm surprised you haven't written your own userspace governor by now. ;o
 
Last edited:
I'm surprised you haven't written your own userspace governor by now. ;o
I honestly think that our custom governor might be the best option.
I just have a whole pile of PCBs here that I need to test and hopefully revive, so I'll take whatever governor already exists ;)
 
When I read governor I have to remember the better sessions of Walking Death ^^ He was whit Negan one of my favorite Bad Guys ^^

I wonder if I can help out test stuff as I get vacations in 3 weeks..


Gesendet von iPad mit Tapatalk Pro
 
Can't you just set the governor in /etc/init.d/cpufrequtils ?

Conservative governor uses small step sizes so that seems good for our more granular frequency spectrum (as well as battery devices)

Ondemand governor can ignore niced processes - cool. I would use this feature if it's in the conservative governor.


You are right, I tested this.
This is probably the way to go, if we already have cpufrequtils installed :)
 
Back
Top