Infatti, forse è anche abitudine .. Ultima cosa, ma ondemandplus spegne un core a schermo off? Come Interactivex del lean tipo...
Inviato dal mio Galaxy Nexus CM 10.1 + LK
Visualizzazione stampabile
Infatti, forse è anche abitudine .. Ultima cosa, ma ondemandplus spegne un core a schermo off? Come Interactivex del lean tipo...
Inviato dal mio Galaxy Nexus CM 10.1 + LK
Eccoti una descrizione del governor fatta da Boype..
This post serves as additional information about ondemandplus and its variables. It is linked to the OP's knowledge-base.
ondemandplus is an ondemand- and interactive-based governor that has additional power-saving capabilities while maintaining very snappy performance. While the interactive governor provides a modern and sleek framework, the scaling logic has been been re-written completely.
Basics about the governor's scaling logic
When the screen is on: First of all, the governor checks the CPU load for the currently set CPU frequency during the last timer cycle. If the CPU load (measured in percent) is higher than the up_threshold, the governor will increase the CPU frequency. Originally in plain ondemand, the CPU frequency is immediately increased to the maximum supported frequency. If the CPU load is lower than up_threshold - down_differential, the governor will decrease the CPU frequency. The frequency to scale down to is calculated like this: (current CPU frequency * CPU load) / up_threshold - down_differential.
In ondemandplus, the downscaling behavior is only very slightly modified. However, the upscaling has been modified to not scale up to maximum frequency immediately. By means of the inter_lofreq, inter_hifreq and inter_staycycles sysfs variables, upscaling is 'dampened' to save battery - a kind of 'barrier' is set, which first has to be breached. For example: inter_lofreq is 729 MHz, inter_hifreq is 1036 MHz and inter_staycycles is 3. This will result in the following behavior when a frequency increase is triggered: In the first timer cycle with high CPU load, the frequency will be set to inter_lofreq (729 MHz). If the load remains high in the next timer cycle, the frequency will be further increased to inter_hifreq (1036 MHz). If the CPU load is still high, inter_hifreq is kept until the inter_staycycles value is reached. In this example, the CPU has been scaled up twice so far, so one more timer cycle of high CPU load is necessary to scale to the maximum CPU frequency. And now - as already indicated - after the a third timer cycle with high CPU load, inter_hifreq can finally be left behind for higher CPU frequencies.
The sysfs variable staycycles_resetfreq merely controls when the staycycle counter is reset to 0, thus effectively re-applying the 'barrier'. So, if staycycles_resetfreq is set to 500 MHz (which equals a sysfs value of 500000), the upscaling barrier is re-established when the CPU is scaled down below 500 MHz.
When the screen is off: CPU scaling is way simpler when the screen is off. When the CPU load is higher than up_threshold, the governor will simply scale up to the next-highest frequency. Of course, it can not be scaled to a higher CPU frequency than the maximum screen-off frequency.
Downscaling works pretty much the same way. When the CPU load is below up_threshold - down_differential, the next lower CPU frequency will be the target.
Governor sysfs tuneables and their effects
timer_rate: The interval in microseconds in which the CPU load is measured. If set to 30000 for example, there will be a check (and maybe a frequency change if necessary) every 0.030 seconds.
up_threshold: If the measured CPU load is higher than this value, the governor will scale the frequency up. Value is in percent. Higher values can cause slower upscaling and maybe slight lags.
down_differential: If the measured CPU load is lower than up_threshold - down_differential, the governor will scale the frequency down. Lower values will cause faster downscaling.
inter_lofreq: The first intermediate frequency to scale to if the CPU load is high.
inter_hifreq: The second intermediate frequency to scale to if the CPU load is high. Can be equal to inter_lofreq.
inter_staycycles: The amount of timer cycles under consistently high CPU load that are necessary to be able to finally scale up to the maximum CPU frequency. 1 timer cycle equals the timer_rate value. If set to 0, the intermediate frequencies are not used, instead the governor will scale up to the maximum CPU frequency immediately.
staycycles_resetfreq: When the CPU frequency goes below this value, the timer cycle counter (counting the high-load-cycles until inter_staycycles is reached) is reset to 0. This effectively re-establishes the intermediate frequency barrier. Value cannot be set higher than inter_lofreq.
Comunque non mi vorrei sbagliare ma pare di no, però usando il raggruppa attività in un core, spesso lavora soltanto un core e l'altro rimane alla minima frequenza. In deep sleep la batteria dura tantissimo..qualche pagina dietro ci sono i miei screen di consumo, con la batteria che ha più di un anno..
from GNexus with Tapatalk2
Ciao ragazzi, è un po strana come cosa, perche io quando uso il telefono in continuazione per un'ora messagiando, navigando e usando tapatalk sotto il WiFi, scendo massimo di un 20% di batteria.
from GNexus with Tapatalk2
Beh se dici che scendi un 20% allora penso che siamo nella normalità, almeno io.
Avevo la luminosità automatica e l'aula era illuminata un poco.
Magari poi dipende pure dalla rom (tu hai la cyano e io la liquid) e dalla batteria (io non la ricalibro da quasi un mese).
Quote:
Originariamente inviato da oleksandr
Ma se metteranno anche il governor hyper, sarà una valida alternativa a ondemandeplus ?
Inviato dal mio Galaxy Nexus CM 10.1 + LK