[Galaxy S II General] droidphile:
Hello again to all the people suffering from Obsessive Kernel Flashing Disorder.:) After i wrote an essay in this thread and bored the readers to death, here is a new thread as a reference to ICS kernel related stuffs. ICS is not a 100% different. But there are differences. Idea here is to understand "How is 3.0 ICS Kernels different from 2.6.35 GB Kernels". Additions, deletions, modifications?

Index:

Post 1: Understanding all the Kernel Tunables

Post 2: Exclusive Features - Dual Booting and BLN Breathing

Post 3: All New Governor - Pegasusq. Parameter Explanations, Sample Tweaks, How to Tweak

Post 4: Kmemhelper Binary Interface - Enjoy Virtual Kernel Hacking

Post 5: Miscellaneous FAQs on Kernel from Different Angles

To begin with we will understand some of the tunables in ICS kernels, taking Gokhanmoral's Siyah kernel as a reference. (Yes, the info here are also valid for other ICS kernels for SGS2). Universal Configurator Interface app ExTweaks has the following tunables with Siyah kernel.

Note: All the tunables explained below may not be available for your current kernel build. Devs tend to experiment by removing some interfaces and adding them back later.

TAB 1

- CPU: Task Scheduler, Hotplugging, Smooth Scaling, Idle States

1) CFS Tweaks:

CFS is the default task scheduler. A task/CPU scheduler does process scheduling, ie manages how the threads, processes or data flows are given access to system resources. (I/O scheduling is different. I/O scheduler schedules I/O requests) CFS uses a binary search tree instead of run-queue method to maintain a timeline of future task execution. Note: Results of task scheduler tuning are experienced only during multi tasking, not during benchmarks.

a) GENTLE FAIR SLEEPERS

Significance: Android UI Interactivity.

Sleeper Fairness is a concept used by CFS which treat sleeping/waiting tasks as if they were in a run queue. This implies tasks which spend most of the time waiting for an user input and such will get a fair share of CPU when they need it. Disabling Gentle Fair Sleepers could improve UI responsiveness.

Tweaking Via Script:

#disable

echo "NO_GENTLE_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features

#enable

echo "GENTLE_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features

b) ARCH POWER

Significance: ARM Topology Awareness.

Arch Power patch causes arch dependent power functions to be used instead of generic high resolution timer ticks and double ticks.

Tweaking Via Script:

#disable

echo "NO_ARCH_POWER" > /sys/kernel/debug/sched_features

#enable

echo "ARCH_POWER" > /sys/kernel/debug/sched_features

2) Hotplug Mode:

Significance: ON/OFF behavior of CPU cores.

Hotplugging as we know dynamically activates second CPU core ON on load conditions and turns second core OFF on low load conditions. Best practice is to use hotplugging instead of single/dual core modes and tweak settings in such a way that until about 800 mhz, only first core is active. This is energy efficient since voltage increase is steep for frequencies above 800mhz. So static power consumption increases sharply and it's better to have two cores handling tasks from here on. According to a test, having only one core online roughly saves about 55% power compared to two cores online. But it's not worth using single core for all frequencies since the device is capable of more.

Sample Value: CPU Hotplug

Tweaking Via Script:

#HOTPLUG

echo "on" > /sys/devices/virtual/misc/second_core/hotplug_on

echo "on" > /sys/devices/virtual/misc/second_core/second_core_on

#SINGLE CORE:

echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on

echo "off" > /sys/devices/virtual/misc/second_core/second_core_on

#DUAL CORE:

echo "off" > /sys/devices/virtual/misc/second_core/hotplug_on

echo "on" > /sys/devices/virtual/misc/second_core/second_core_on

3) load_h0, load_l1:

Significance: Thresholds to ON/OFF second CPU core

Load-High-0 and Load-Low-1 are UP/DOWN thresholds to turn ON and turn OFF second core. When load on first core is greater than loadh0, second core comes online. When average load on both cores is less than loadl1, second core goes offline. Do not overload first core before turning second core on aka do not use high thresholds. See Q&A at the bottom of the post

Sample Values: Less Aggressive: load_h0 50, load_l1 20. More Aggressive: load_ho 30 load_l1 20.

ICS hotplugging logic is different from GB hotplugging. To get the same responsiveness as in gingerbread, use more aggressive(reduced) load_h0 thresholds.

Valid Values: 0 to 100%

Tweaking Via Script:

echo "30" > /sys/module/stand_hotplug/parameters/load_h0

echo "20" > /sys/module/stand_hotplug/parameters/load_l1

4) min_rq, load_rq:

Significance: Enhance hotplugging via CPU Run Queue and Process Priorities

ICS has multiple hotplugging concepts. What's normally used is Standalone Hotplug. We also have the one like GB's (remember loadh, loadh_scroff, loadl, etc). min_rq - Minimum Run Queue and load_rq Load on Run Queue are two parameters to increase multi thread awareness of ICS hotplugging. With these parameters we achieve the goal of turning of second core if fewer task threads are running - even if load is high.

If no of threads running on a Core is less than min_rq and load of that Core is less than load_rq, second core is turned off. Note that the load threshold considered here is for only one core (unlike load_l1 which takes average load on cores to make turning-off-second-core decision).

Example: Let min_rq=2 and load_rq=40%. Suppose both cores are online. Average load on cores has not dropped below load_l1 so it's still not time to turn off second core. But say only one thread is running on second core and load on that core is 30%. Then second core will be turned off.

Sample Values: min_rq 2, load_rq 20%

Valid Values: min_rq: 0, 1 and 2. load_rq: 0 to 100%

Tweaking Via Script:

echo "2" > /sys/module/stand_hotplug/parameters/min_rq

echo "20" > /sys/module/stand_hotplug/parameters/load_rq

5) rate:

Significance: Hotplug Sampling Interval

Every rate jiffies, load is sampled and if found to be more than loadh0, second core is turned ON. One jiffy is the time taken to complete one tick of the system timer. Sgs2 timer frequency is 200hz. So the value divided by 200 gives the equivalent seconds or in other words, one jiffy = 5 milliseconds in GS2 terms.

Sample Values: rate 100.

Valid Values: 50 to 1000 jiffies, in terms of 50s.

Tweaking Via Script:

echo "100" > /sys/module/stand_hotplug/parameters/rate

6) freq_min:

Significance: Cut-off frequency for second core to turn ON

'Threshold' frequency for second core to turn ON during hotplugging. If current frequency <= freq_min, second core will not turn on even if the load has crossed loadh0. CPU runs efficiently if only single core is used until about 800 mhz and both the cores after 800.

Sample Value: freq_min 800000

Valid Values: All the values in freq_table

Tweaking Via Script:

echo "800000" > /sys/module/stand_hotplug/parameters/freq_min

7) CPU Idle States:

Significance: Power saving CPU idle modes that are 'encountered' between screen-off and deep-sleep.

Unlike 8 idle states supported by Nexus OMAP4, GS2 Exynos supports only 3: IDLE, AFTR, LPA.

IDLE - Clock is gated but power on CPU core remains (static power consumption still active)

AFTR - Clock is gated, power on CPU cores removed and L2 cache power remains. Static power consumption mostly eliminated.

LPA - Cache power removed.

AFTR or LPA cannot be entered if second core is active.

Sample Values: Idle Mode 3 (AFTR+LPA), to save battery.

Valid Values: 0, 1, 2, 3

Tweaking Via Script:

#AFTR+LPA

echo "3" > /sys/module/cpuidle_exynos4/parameters/enable_mask

#IDLE+LPA

echo "2" > /sys/module/cpuidle_exynos4/parameters/enable_mask

#AFTR only

echo "1" > /sys/module/cpuidle_exynos4/parameters/enable_mask

IDLE only

echo "0" > /sys/module/cpuidle_exynos4/parameters/enable_mask

8) Sched_mc:

Significance: Increases multi-core awareness!?

Sched_mc aims to schedule tasks between multiple cores in the CPU. Sched_mc can be a) OFF (value 0), b) load balance (value 2) the cores by keeping the load even between them or c) power-save balance (value 1) by loading first core until it's 100% loaded. Hotplugging does load balancing already by taking care of thresholds, run queues, process priorities, cut-off frequency, etc. So there's no use of sched_mc = 1. Powersave balancing which overloads first core will increase the time to relieve first core (as compared to same task balanced between both the cores). This will cause delay to hit deep-idle states, since only first core can enter AFTR/LPA states.

Disable sched_mc. There could be only one situation where load balancing or weird-overloading of first core can be useful - when we use dual core mode. Sched_mc is valid only when both cores are online. If someone uses dual-core mode sched_mc is worth a try to handle task-loads across cores.

Sample Values: sched_mc 0

Valid Values: 0, 1, 2

Tweaking Via Script:

#disable sched_mc

echo "0" > /sys/devices/system/cpu/sched_mc_power_savings

#enable first core overloading

echo "1" > /sys/devices/system/cpu/sched_mc_power_savings

#load balancing

echo "2" > /sys/devices/system/cpu/sched_mc_power_saving

9) smooth_target, smooth_offset, smooth_step:

Significance: CPU Throttling

These params helps in 1) Throttling CPU at higher temperatures 2) Control Ondemand based governors' urge to jump to maximum frequency too often by jumping the CPU to an intermediate frequency first. If we're not interested in either of them, leave it as 0 0 0. NOTE: Smooth scaling is enabled only for Ondemand and Pegasuq governors.

Sample Values: smooth_target 2, smooth_offset 2, smooth_step 2

Valid Values: 0, 1, 2, 3, 4 (for all three params)

Tweaking Via Script:

echo "1" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target

echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset

echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step

10) smooth_level:

Significance: Intermediate Step Before Scaling Max Freq

smooth_level is a standalone parameter to control smooth scaling. When ondemand/pegasusq governors instruct CPU driver to scale CPU up to max frequency, CPU driver first scales CPU to smooth_level then on next sampling to highest frequency. Only goal here is to save some battery.

Sample Values: smooth_level 800mhz

Valid Values: Level number of any frequency between your scaling min frequency and scaling max frequency.

Tweaking Via Script:

#Level 8 in 18step freq table is 800mhz

echo "8" > /sys/devices/system/cpu/cpu0/cpufreq/smooth_level

11) CPU Step Counts:

Significance: Set of Available Frequencies aka 'Tightness of Freq Table'

Some are O.K with Samsung defaults of 5 frequency steps, some users need a 1400 on top, some needs a 1600 too. Some would like to set intermediate frequencies in between. To satisfy everyone, we have configurable CPU Frequency Table to echo custom frequency steps. Possible step counts (selectable from ExTweaks) are

5 - Samsung default: Good old 200-500-800-1000-1200.

6 - Sammy default plus 1400 mhz: 200-500-800-1000-1200-1400

7 - 6 Step plus 1500: 200-500-800-1000-1200-1400-1500

8 - 6 Step plus 100 in the 'bottom' and 1600 on 'top': 100-200-500-800-1000-1200-1400-1600

9 - 8 Step plus 1500: 100-200-500-800-1000-1200-1400-1500-1600

18 - All possible 18 steps.

Note: Any number of steps between 3 and 18 is possible (use script). Only condition is 500,800 and 1000 should be present in the list.

Sample Values: Select any step count you like

Valid Values: 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 700, 600, 500, 400, 300, 200, 100, 50, 25. (In Mhz. Note that you echo to the table as Khz)

Tweaking Via Script:

echo "1600 1400 1200 1000 800 500 200 100" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

12) Scaling Min & Max Frequencies:

Significance: Frequency Range to be Used from Frequency Table

Any governor will scale CPU up and down between scaling_min_frequency and scaling_max_frequency. We change value of these two to UC/OC

Sample Values: scaling_min_frequency 200 and scaling_max_frequency 1200

Valid Values: Any frequencies from frequency table. Only condition is scaling_max_freq should be greater than scaling_min_frequency.

Tweaking Via Script:

echo 200 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

echo 1200 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

TAB 2

- GPU: GPU behavior. This matters more than CPU UV w.r.t Screen-On power savings!

1) GPU Frequency Steps:

Significance: Configurable GPU Frequency Steps

There are plenty of frequencies supported by the MALI400. Valid frequencies are 800 divided by an integer not greater than 20. I would recommend using energetically efficient GPU freqs. Note that any Nth step can not be less than (N-1)th step.

Sample Values: 160 200 267. If you want more frames, use 200 267 400.

Valid Values: 400 267 200 160 133 114 100 89 80 73 67 62 57 53 50 47 44 42 40

Tweaking Via Script:

echo "160 200 267" > /sys/class/misc/gpu_clock_control/gpu_control

2) GPU Voltages:

Significance: Set enough voltage to support your underclocked or overclocked GPU frequency steps.

GPU Undervolting (if not taken care of) has some worse side effects compared to CPU UV. Your game and navigation app will crash. I'd recommend to use stock voltages. Or just a -50mV UV for each step.

Sample Values: 950 1000 1050

Valid Values: 800mV to 1200 mV at 50mV steps.

Tweaking Via Script:

echo "900000 950000 1000000" > /sys/class/misc/gpu_voltage_control/gpu_control

3) GPU UP and DOWN Thresholds:

Significance: When should GPU scale up and down across GPU frequency steps.

The four thresholds are threshold to switch to second step, switch back to first step, switch to third step, switch back to second step. We do not want GPU to scale up immediately after scaling down to a frequency. This implies the thresholds are overlapping load-evaluations. Use up-thresholds of the range 80-90. To calculate down-thresholds in such a way that overlapping is prevented, for a set of two freqs, find out what percentage of higher frequency is lower frequency, and reduce 5-10 % from the resultant value. Ex: for 160 to 200, 160 is 80% of 200. Reducing 10% gives 70%.

(If you like the 'good old' two frequency step, set Threshold-2-UP to 100 so that only First two steps are used and third step will never be active)

Sample Values: 85 70 85 65 (For GPU steps 160 200 267). OR 85 65 85 55 (For GPU steps 200 267 400).

Valid Values: 0 to 100%

Tweaking Via Script:

echo "85% 70% 85% 65%" > /sys/class/misc/gpu_clock_control/gpu_control

4) GPU Stay Counts:

Significance: Delaying next sampling/stay at a GPU step for longer time.

Staycount is the no of cycles to stay at each GPU step. It is recommended to leave it as default 1 1 1. A check in dvfs part make sure that changing frequencies happens only after staycount expires - regardless of load crossing thresholds.

For example : Staycount of 1 0 2 for 160 200 267 steps implies => i) A transition from 160 to 200 happens only a after a minimum of 1 second even if load on 160 exceeded the threshold before 1 second expired. ii) A transition from 200 to 267 or 160 can happen anytime load crosses threshold. iii) A transition from 200 to 267 happens only a after a minimum of 2 seconds even if load on 160 exceeded the threshold before 2 seconds expired.

Sample Values: 1 1 1

Valid Values: 0, 1, 2, 3, 4, 5 Seconds

Tweaking Via Script:

echo "1 1 1" > /sys/class/misc/gpu_clock_control/gpu_staycount

TAB 3

- SCREEN: Touch sensitivity, Brightness curve

1) Touch Move Sensitivity:

Significance: Improving touch sensitivity

Supported values are between 0 and 20. Lower value is more responsive. But setting it too low will cause swipes to be registered as clicks.

Sample Value: 7 pixel

Valid Values: 0 to 20 pixels

Tweaking Via Script:

echo "7" > /sys/devices/platform/s3c2440-i2c.3/i2c-3/3-004a/mov_hysti

#Another touch sensitivity parameter is tsp_threshold which can take the values between 40 and 80 at steps of 10. Lower value is more responsive.

echo "50" > /sys/devices/virtual/sec/sec_touchscreen/tsp_threshold

2) min_bl, min_gamma, max_gamma:

Significance: Brightness Response Curve.

If you don't want lowest brightness to be very low, use 30 1 20 which are stock values. We will have lowest brightness or zero gamma for brightness level read from sensor < min_bl (30 here). Brightness levels above that is linearly mapped to [min_gamma:max_gamma] ( [1:20] here). To decrease minimum brightness level (some users find the lowest brightness level too bright in dark conditions), increase min_bl.

Sample Values: 30 1 20 (for stock experience) OR 50 0 15 (for low lowest brightness level and low highest brightness levels)

Valid Values: min_bl 0 to 150, min_gamma 0 to 20, max_gamma 0 to 20

Tweaking Via Script:

echo "30" > /sys/class/misc/brightness_curve/min_bl

echo "1" > /sys/class/misc/brightness_curve/min_gamma

echo "20" > /sys/class/misc/brightness_curve/max_gamma

3) Gamma Shift

Significance: Gamma Correction

Gamma in the simplest form is a non linear operation to code and decode luminance of display systems. If display is not properly gamma encoded, human eye will not be able to differentiate highlights and details. Keep in mind that brightness perception of human eye is non-linear (ie, relationship between perceived brightness and luminance is non linear). Better perception is achieved at lower luminance level.

Use negative values for darker image system and positive values for brighter.

Sample Values: 0 (stock) or -15 (darker)

Valid Values: -50 to +50 (at steps of 1)

Tweaking Via Script:

echo "0" > /sys/class/lcd/panel/user_gamma_adjust

4) Vibration Intensity

Significance: Vibration Intensity for Notifications

You can change the intensity of vibration for calls, notifications, htpic feedback, etc. Change is most likely noticable only in aosp/aokp roms.

Sample Values: 6 (stock) or 2 (low intensity)

Valid Values: 0 to 6 pixels(at steps of 1)

Tweaking Via Script:

echo "6" > /sys/devices/platform/tspdrv/vibrator_level

TAB 4

- BLN: Backlight Notification and LED Timeout Settings

1) BLN

Significance: Notification for Missed Calls, SMSes, Emails, etc

GS2 doesn't have led notification built in. Instead the capacitive touch keys were hacked to lit up when some notification arrives.

Tweaking Via Script:

#ON

echo "1" > /sys/class/misc/notification/notification_enabled

#OFF

echo "0" > /sys/class/misc/notification/notification_enabled

2) Notification Timeout

Significance: Timeout for an Active BLN Notification

Timeout can be anything from a minute. Set it according to your taste and need.

Sample Values: 10 minutes

Valid Values: 1 minute to 2 hours to anything

Tweaking Via Script:

#In milli secs. Minutes*60*1000. Ex: For a 15 minute timeout set 15*60*1000 = 900000

echo "600000" > /sys/class/misc/notification/notification_timeout

3) BLN Effect

Significance: Pattern of Notification - breathe, static lights or blink

Breathing effect is achieved by supplying a lower to highest voltage at a particular step to backlight with a small pause/sleep in between. This is breathe Up. To breathe Down, voltage is supplied in the reverse order with a pause in between.

Tweaking Via Script:

#enable steady/static lights

echo "0" > /sys/class/misc/notification/breathing

#enable breathing/blinking

echo "1" > /sys/class/misc/notification/breathing

#breathing config - Min Voltage, Max Voltage (in mV), period/pause in between voltage changes (millisec), voltage step (mV)

echo "2500 3300 70 50" > /sys/class/misc/notification/breathing_steps

echo "3300 2500 70 50" > /sys/class/misc/notification/breathing_steps

#blinking config - set same voltages as min and max. It blinks

echo "2500 2500 500 100" > /sys/class/misc/notification/breathing_steps

echo "3300 3300 500 100" > /sys/class/misc/notification/breathing_steps

4) LED Timeout

Significance: Timeout for Backlights to stay On after touching buttons/screen

In Samsung roms, system settings can be used to achieve the same. Leave extweaks settings disabled for sammy roms. Since aosp roms do not have led timeout settings by default, use extweaks/script. If you want it always enabled, use settings in the rom.

Tweaking Via Script:

#backlights always off

echo "0" > /sys/class/misc/notification/led_timeout

#backlights turns off after a timeout after a touch. Unit - millisec

echo "1500" > /sys/class/misc/notification/led_timeout

5) LED Fadeout

Significance: Fadeout effect instead of LEDs normally turning off after touching buttons/screen.

Lights fading out can be an eye candy.

Tweaking Via Script:

echo "1" > /sys/class/misc/notification/led_fadeout

6) LED on Touch

Significance: Turn ON LEDs on Touching Screen

This is samsung default behavior but aosp/aokp roms miss this feature. If you like capacitive buttons to lit up on screen touch (along with buttons touch), enable this option.

Tweaking Via Script:

echo "1" > /sys/class/misc/notification/led_on_touch

7) Test BLN

Significance: Test BLN to see if everything works as you expected

Testing can be achieved by a script too like given below.

Tweaking Via Script:

SLEEPING=`cat /sys/power/wait_for_fb_sleep`

if [ "$SLEEPING" = "sleeping" ]; then

sleep 1

echo "1" > /sys/class/misc/notification/breathing_steps

8) LED Voltage Levels

Significance: Brightness of Touchkey Light

Minimum of 2550mV is required to lit up touchkey. Default is 3000mV. Max is 3300mV.

Tweaking Via Script:

echo "3000" > /sys/devices/virtual/sec/sec_touchkey/touchkey_brightness

TAB 5

- MISC: Governor, Scheduler, Miscellaneous Tweaks

1) Backup EFS: Backup your precious EFS partition to use in the future to recover a lost IMEI.

2) Android Logger: Enable/Disable Logging. Leave it enabled. Would be helpful to produce logcat and last_kmesg when you have a crash or freeze.

3) Default Ondemand Suspend Freq: Max frequency that will be used during screen-off state if Ondemand is the active governor. 500000 (500 mhz) is the most sensible value.

4) Default CPU Governor: Use whichever you like. Ondemand is good enough.

5) Default I/O Scheduler: Use whichever you like. I use sio/bfq.

6) Charge Current: Since it was proved that i9100 Li-ion battery charge current can only be either of 450mA and 650mA, leave it at AC:650, MISC:450,USB:450 OR AC:650 MISC:650 USB:450

Tweaking Via Script:

echo "650 650 450" > /sys/devices/virtual/misc/charge_current/charge_current

7) Reset Fuel Gauge Chip: After a low-battery reboot if the battery shows very low and incorrect percentages since true battery capacity failed to accurately synchronize with the fuel gauge, press the button and wait for sometime. An alternative is to charge full->discharge full->charge full.

8) Remove Root: Some apps detects root and refuse to work if found. In such cases, or if some apps are freezing in a while, remove root and re-install root. Pressing the button will remove Superuser.apk and SU binary.

9) Install Root: Tries to install root after a removal. Copies Superuser.apk and SU binary. If this fails, check 'Auto-Install Root' and reboot.

Randomly Asked Questions:

Q. "Why don't you just give a set of battery friendly or performance friendly tweaks to be used with ExTweaks app instead of lengthy sentences and crap?"

A. Three reasons: 1) Every device is different. 2) What i think are battery friendly/performance friendly settings may not please you. 3) It's useless to copy a setting without understanding what it does.

So i'm trying to give an almost accurate picture of effect of changing values of tweakable parameters. Then you will know what value and settings is best whether you're a battery-freak, performance-freak, 'I want it to be balanced'-freak. You will never have to ask in a thread "What is the best settings for this kernel".

Q. "What are the power domains i should be aware of so that i can think this way: Tweak settings related to each domain to make the most out of my kernel"

A. CPU cores (and L2 cache), GPU, Memory Interface and Audio/Video IP blocks

Q. "How about a short brief algorithm which explains working of hotplugging where i can see how are each parameters used."

A. Note the parameters with red font color. Those are the tweakable hotplug parameters mentioned above.

FUNCTION: standalone_hotplug()

Takes three parameters: load, min_rq, and minimum_cpu_run_queue_length

WORKING:

if ( both cores online AND [average_load < load_l1 OR current_cpu_frequency <= freq_min] ) RETURN HOTPLUG_OUT

else if ( only first core online AND average_load > load_h0 AND current_frequency > freq_min) RETURN HOTPLUG_IN

else if (both cores online AND min_rq < 2 AND load on the core corresponding to minimum_cpu_run_queue_length < load_rq) RETURN HOTPLUG_OUT;

SAMPLING PART:

Retrieve the value returned by standalone_hotplug by passing current load, min_rq and calculated minimum_cpu_run_queue_length

if (HOTPLUG_IN was returned AND second core is OFF)

Turn ON second CPU

Next sampling at 4 times the value of rate

else if (HOTPLUG_OUT was returned AND second core is ON)

Turn OFF second CPU

Next sampling at the value of rate