REMOVED

Status
Not open for further replies.
Search This thread
By:
Advanced…
Asmodicus

Asmodicus

Senior Member
Aug 22, 2010
491
664
Tennessee
AndreiLux said:
I actually missed what happened here, maybe for the better.
Although certainly not everything is wrong, the vast amount of information is wrong. It's supposed to be a "simple" introduction to things but it severely veers off cliff on several things. The explanations seems to be actually copied, or may I say, "rewritten in OP's own words" (Probably why so much is wrong) from all over the place, with little actual knowledge on the topics. Some of the governor explanations really sticked out as painfully wrong and I corrected some of them.

I doubt OP can actually explain anything in this "guide", as I've said most of it is wrong and copied out of context. The zRam explanation is actually out of this world:
Disk paging doesn't even exist on a phone, unless you have a custom kernel which supports, and you yourself actually created a swap space. Fragmentation doesn't exist / doesn't matter on solid state memory.

This really shouldn't be a sticky, and people really would be better off following other guides.
Click to expand...
Click to collapse

I assume, in your own way, that you're trying to help. Thing is, your condescending tone makes no one want to listen to you. Instead of coming into this thread offering your criticisms, you could offer your assistance to edit the OP. Maybe you're not deliberately trying to be so abrasive, but that's the way you come across. To me, anyway.

MBQSniper is nothing if not helpful, patient, and kind when helping other users. None of us know everything. If we did, we wouldn't be here.
 
Last edited:
  • Like
Reactions: MBQ_, playabigfoot and Nephilim
mamba720027

mamba720027

Senior Member
Sep 24, 2010
1,825
2,884
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

MBQsniper said:
Don't care

Thx

Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse

Actually you should care because you're posting mostly wrong information while others are blindly following.

I rember reading up on governors in the link Andrei posted and from another older source long ago and comparing what I understand from useing all those governors and reading up on each of them with what u wrote in your guide is totally different. I can see you're trying to simplify it for everyone to understand in your own way but its not exactly correct and can be confusing cause somethings you mention are unrelated.

Sent from my GT-I9300 using xda app-developers app
 
  • Like
Reactions: tuemdeluxe, MBQ_, nikulogical and 7 others
Nephilim

Nephilim

Senior Member
Aug 16, 2010
7,084
9,869
Milwaukee
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

mamba720027 said:
Actually you should care because you're posting mostly wrong information while others are blindly following.

I rember reading up on governors in the link Andrei posted and from another older source long ago and comparing what I understand from useing all those governors and reading up on each of them with what u wrote in your guide is totally different. I can see you're trying to simplify it for everyone to understand in your own way but its not exactly correct and can be confusing cause somethings you mention are unrelated.

Sent from my GT-I9300 using xda app-developers app
Click to expand...
Click to collapse

This is the tone AndreiLux should have taken. You stated your criticism in a respectful and constructive way. Thank you. :)

Sent from my AK Dummy Powered AOSPA Galaxy Nexus
 
  • Like
Reactions: Asmodicus, omid900 and FoleyRose
renaud

renaud

Inactive Recognized Developer
Aug 18, 2010
2,332
2,212
Braine-l'Alleud
Thanks for the suggestion on using lux for autobrightness, I didn't know this app, but it works nicely.

I know MBQsniper is trying to help people, and he does in many parts of the guide. But unfortunately the governor part is ridden with mistakes, and spreading wrong info is probably not the best way to help people as once you have learned something with a mistake, it's hard to forget it.

fsync section should probably be changed from
Code: 
FSYNC:
Faster file reading/loading with a risk of crashing your files on your phone

to
Code: 
FSYNC:
When disabled, provides faster writing (not reading) of files with the risk of data loss if the phone crashes or is shut down improperly.
 
Last edited:
  • Like
Reactions: oli20021978, BlackBurn85, FoleyRose and 1 other person
MBQ_

MBQ_

Senior Member
Sep 3, 2011
14,799
22,998
28
Phoenix, Arizona
MBQonXDA.com
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

renaud said:
Thanks for the suggestion on using lux for autobrightness, I didn't know this app, but it works nicely.

I know MBQsniper is trying to help people, and he does in many parts of the guide. But unfortunately the governor part is ridden with mistakes, and spreading wrong info is probably not the best way to help people as once you have learned something with a mistake, it's hard to forget it.

fsync section should probably be changed from
Code: 
FSYNC:
Faster file reading/loading with a risk of crashing your files on your phone

to
Code: 
FSYNC:
When disabled, provides faster writing (not reading) of files with the risk of data loss if the phone crashes or is shut down improperly.
Click to expand...
Click to collapse

Thank you

Will change it when I have time

I'll give credit to you

Sent from my Galaxy Nexus using xda premium
 
  • Like
Reactions: samersh72 and FoleyRose
Garuxa

Garuxa

Senior Member
May 12, 2011
580
218
Santiago
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

Excellent and simple. What better than that?
Thanks for this great contribution :)

I add subscription for this

Cheers!

Enviado desde mi GT-I9100
 
  • Like
Reactions: MBQ_
D

dirtyreturn

Senior Member
Aug 14, 2011
1,138
252
Nexus 7
Huawei Nexus 6P
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

@MBQsniper. You were right about the pdroid patch, it must have been faulty for that cm build. I do believe there were some issues around that time +/maybe/+ with getting things sorted with auto_patcher. Since then I flashed 4.2.2 stock and patched a cm10.1 rom. All works as it did on previous phones.
 
  • Like
Reactions: MBQ_
D

dirtyreturn

Senior Member
Aug 14, 2011
1,138
252
Nexus 7
Huawei Nexus 6P
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

For the whole TCP thing. When referring to packets -that means data transfer?
For the I/O schedulers- that prioritizes the way the apps are handled? I am taking a stab in the dark here- all of these are in some mathematical sequence or something?
For the cpu governors-is it ok to say processor? If it is ok to say that.. is that what the governors take care of?
@MBQsniper? Could you add to the OP if it is not too much trouble.. a description of what each actually are? I'm pretty sure I realize that if reading each description everything would come together. It may / or may not depending on your stance in the matter make even more sense to have a description before the governor /scheduler/tcp to kind of have the full picture before hand and then have the little details.
This is a reference thread it seems. I hope you would include those even if there is google. I think, in my opinion at least, it would simplify things. Though I am not an advanced user if you could maybe take it into consideration. Thanks.
 
  • Like
Reactions: MBQ_
faintless

faintless

Member
Feb 23, 2013
6
4
IMHO

OnDemand:

Basically, this Governor will allow your phone to use CPU speeds on demand, meaning.. If you're sending a text, your phone wont require much memory, but if you're playing a graphically intense game, it will use both cores, most likely at your highest set CPU speed, and will idle back down when you finish your game.
Click to expand...
Click to collapse
All governor except hotpluggings ones uses both cores LOL anyway yes, but cpu scales to max when reach threshold, if you are gaming or messagging too
Interactive:
The same idea of Ondemand, but Interactive scales your CPU to the highest frequency faster than Ondemand does.

InteractiveX(v2):

The same as Interactive, but when you turn your screen off it forces the second CPU core offline until the screen turns on again.
Click to expand...
Click to collapse
I addict it's hightly optimized thanks project butter, from 4.1 it scales at hispeed_freq when you touch screen and it's updated and review daily
InteractiveX is different from first one, first one is more updated and work as new governor , this interactiveX work as first interactive you describe, ondemand, but more fast scales


Wheatley:

One of the favored Governors of users. It is based on Ondemand, but was built with performance in mind, and maxes out c4 time (Simply put: It keeps your phone nice and fast). When opening and running apps, it will ramp up the CPU. Reduced sampling intervals was included as well, and a unique feature of this Governor is the Sampling interval can be lower than the target residency, which prevents wakelocks without hurting battery life.
Click to expand...
Click to collapse
I tried to test it alot of times, too high battery
[/SIZE]
 
  • Like
Reactions: MBQ_
Heisenberg420

Heisenberg420

Senior Member
Apr 28, 2011
2,286
1,015
Philadelphia
Google Pixel 6
OnePlus 11
Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

Very useful thread, great info.

JoyFull117 said:
Would be cool if you could explain the different governor settings like "Target-loads" or "timer-slack" ;)

And thanks for this great thread =)
Click to expand...
Click to collapse

I wanted to know about these interactive parameters (target loads, timer slack)

I've always been using conservative based governors but after learning about how interactive works and tweaking it a little I'm getting the best battery life I've seen on my phone (gs3)
 
Last edited:
  • Like
Reactions: MBQ_
Status
Not open for further replies.

Similar threads

mskip
[GNEX TOOLKIT V11.1.0] Drivers, Backup, Unlock, Root, Recovery, Flash + MORE [GSM]
Replies
4K
Views
2M
mskip
mskip
mike1986.
[ROM] Android Revolution HD 11.0 | High Quality & Performance | GSM | Legendary
Replies
8K
Views
2M
R
Reviz
Wartickler
[GUIDE] Internal Memory Data Recovery - Yes We Can!
Replies
1K
Views
1M
eagleagleblissempire
eagleagleblissempire
osm0sis
[REF] [RADIO] [GSM] Galaxy Nexus GT-i9250 Baseband Collection & Discussion
Replies
3K
Views
1M
T
TG09
benkxda
  • Locked
[INDEX] Samsung Galaxy Nexus - ROMs, Kernels, MODs, Recoveries, Themes [16 Jun 2017]
Replies
435
Views
1M
Thanos
Thanos

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 264
    MBQ_
    MBQ_
    --
    View
    14
    AndreiLux
    AndreiLux
    OnDemand:

    Basically, this Governor will allow your phone to use CPU speeds on demand, meaning.. If you're sending a text, your phone wont require much memory, but if you're playing a graphically intense game, it will use both cores, most likely at your highest set CPU speed, and will idle back down when you finish your game.
    Click to expand...
    Click to collapse
    No.

    It doesn't require much memory? What? CPU governors control CPU frequency, memory has nothing to do with this. Ondemand also has nothing to do with cores as it's not a hotplug aware governor.

    Ondemand stands for that it scales up on load in frequency and then detects the load and scales back to a frequency which is fullfills the "demand" of the current load dynamically.

    OndemandX:

    The same idea of Ondemand, but when the screen turns off, the max screen off profile is 500MHz.
    Click to expand...
    Click to collapse
    And the max screen off profile is what? It's maximum frequency the CPU is allowed to.

    Interactive:

    The same idea of Ondemand, but Interactive scales your CPU to the highest frequency faster than Ondemand does.
    Click to expand...
    Click to collapse
    No it doesn't.

    Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency.

    Conservative:

    Slower CPU scaling, less aggressively as well. For example, lag will occur if using this Governor while running multiple apps, because the idea of this kernel is to be as conservative as possible.
    Click to expand...
    Click to collapse
    No it doesn't.

    Conservative means that it scales conservatively, not that it is conservative. It pretty much very similiar to Interactive in that it scales up and down in frequency steps. It actually can be one of the most aggressive governors out there.
    Intellidemand:

    An intelligent Ondemand. It acts like Ondemand if the GPU gets busy, but it loads the CPU frequencies up just a tad faster and more efficient than Ondemand.
    Click to expand...
    Click to collapse
    And what does it do when the GPU is not busy? First of all it is broken in the regard of actually even checking GPU load, which is the one single thing which sets this apart from Ondemand, and has a minimum frequency in such cases. Secondly, it's identical to Ondemand in all other situation.

    Wheatley:

    One of the favored Governors of users. It is based on Ondemand, but was built with performance in mind, and maxes out c4 time (Simply put: It keeps your phone nice and fast). When opening and running apps, it will ramp up the CPU. Reduced sampling intervals was included as well, and a unique feature of this Governor is the Sampling interval can be lower than the target residency, which prevents wakelocks without hurting battery life.
    Click to expand...
    Click to collapse
    No.
    (Simply put: It keeps your phone nice and fast)
    Click to expand...
    Click to collapse
    No, it means that it improves battery by increasing the time spent in the C4 low-power state.
    When opening and running apps, it will ramp up the CPU.
    Click to expand...
    Click to collapse
    As any other governor.
    and a unique feature of this Governor is the Sampling interval can be lower than the target residency, which prevents wakelocks without hurting battery life.
    Click to expand...
    Click to collapse
    Wakelocks have nothing to do with governors.
    Hotplug:

    Based off of Ondemand. It allows a CPU to go offline with minimal usage. When you're sending messages, browsing settings, or other simple tasks, most likely one of your CPUs will be offline, which means in the long run, it will increase your battery life. When your screen goes off, it will shut off a core of your phone, which drastically improves battery life.
    Click to expand...
    Click to collapse
    Actually when your screen goes off all your cores go off. What it does is that it limits itself to 1 core when doing activity when the screen is off.
    PegasusQ:

    Samsungs Governor for multi-core phones. Based off of Ondemand. This kernel controls hotplugging as well, but doesn't hotplug a CPU (unless the developer changed the kernel to do so) when the screen is on.
    Click to expand...
    Click to collapse
    Well does it do hotplugging or not? Yes it does, even without the developer.


    I got tired by now and I even left out all the ancient governors. More tomorrow. I hope some people get the point I'm trying to make here, who allowed this to be stickied?
    View
    10
    mamba720027
    mamba720027
    Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

    MBQsniper said:
    Don't care

    Thx

    Sent from my Galaxy Nexus using xda premium
    Click to expand...
    Click to collapse

    Actually you should care because you're posting mostly wrong information while others are blindly following.

    I rember reading up on governors in the link Andrei posted and from another older source long ago and comparing what I understand from useing all those governors and reading up on each of them with what u wrote in your guide is totally different. I can see you're trying to simplify it for everyone to understand in your own way but its not exactly correct and can be confusing cause somethings you mention are unrelated.

    Sent from my GT-I9300 using xda app-developers app
    View
    9
    The-Captain
    The-Captain
    Back on-topic here guys. I don't think AndreiLux intended to come off as saying everything in this thread was wrong, but just wanted to contribute in making sure it was correct. No more post in here about if it was rude or not though, this thread has been derailed enough. Thanks.

    ~ The-Captain
    View
    8
    B
    borizz27
    Oh, I forgot to tell you about IO schedulers.

    Linux (the kernel) was written in a time where spinning disk hard drives were the norm (yeah, they're still working on it, but bear with me here). The problem with these hard drives is that while they can do a linear read with pretty amazing speed, they suck at random reads. This is because there is an arm with a read/write head at the end that has to swivel around to where the data is on the disk, and then it has to wait for the right data to spin under the arm for it to read. This swiveling and waiting is called seeking, and the time it takes to do is called seek time.

    When you have a lot of concurrent reads going on (multiple things being read at the same time), this means that the data throughput grinds to a near stop because the head is moving around all the time.

    IO schedulers try to optimize this by grouping up nearby reads so fewer costly movements have to be made. There's a few different takes on this, so let me explain a really simple one: You start at the inside of the disk. Sort all the queued reads into order from inside to outside of the disk. Then do them all. Done. Now move the head back and do it again (or start from the other end). Less time is spent moving, more time is spent reading data. Or with an example:

    Say you want to read blocks 18, 94, 19 and 46. If you them in the order given you have to seek after 18 to 94, then almost all the way back to 19, then up to 46. That's 3 movements. Now if you reorder them, you get 18, 19, 46, 94. You only have to move twice now, from 19 to 46 and then to 94. That's faster.

    Other schedulers try to anticipate reads (you read this part, you probably want the next part so we will wait a really short while to see if you do, then move on). The deadline scheduler tries to reorder reads for optimal access but aims to process each read within a certain time of it being queued. Really smart people have worked hard on these schedulers, and they're very cool pieces of code.

    "But borizz27, there's no hard drive in my phone, it's all solid state memory with almost no seek times!" You're right. There isn't. "Then what's the point of the scheduler?" There isn't.

    You'd be hardpressed to find differences between the No-Op scheduler (which does nothing, no op meaning No Operation) and any other scheduler on flash memory where the seek time for the next block of data in a linear read is the same as for the next block on the "other side" of the drive. This very fast seeks is the same reason you don't have to defragment SSDs, by the way.
    View

New posts