Hey all,
Can someone explain what this Linaro thing I hear about is, and what it means to us Nexus owners? Is it just something that is incorporated into the kernel, our the ROM?
Thanks in advance
Swiped on my Gnex
It is, in simple terms, really optimized code.
"Long is the way, and hard, that out of hell leads up to light."
yarly said:
Linaro is basically some compiler optimizations and tweaks. It turns off some strict checking the compiler normally does so it can use a previously unavailable mode of optimization during the process that converts the programing language into machine readable code (basically what a compiler does for those that didn't know). Any performance increase is in tasks that the CPU does and those are much more limited on Android 4.0 than previously. It's not going to make your games run faster and if it does much of anything, it *might* make a few things that are not already cached (stored) in memory load a little faster, but that's rather subjective as of now.
The Linaro team's demo benchmarks that were eaten up by the Android linkbait blogs and the community as a whole were also misleading. They showed framerates at double what they were normally, but this was only due to their benchmarks doing software rendering (thus using the CPU) and not capped at 30fps because on the non-linaro toolchain, it uses double buffering with gpu rendering combined with vertical sync (vsync). PC gamers might know the term from triple buffering (to avoid the latency [lag] issues caused with using vsync) where you're capped at 60fps while using vsync due to staying in sync with the display refresh rate (60hz). The only performance it might do for graphics is where something is still using software rending on Android 4.0, which isn't too many areas.
Someone is bound to read this though and say, "But yarly, isn't 60fps better than 30fps so we should disable GPU rendering right?" No, lol. GPU handles graphics much more efficiently than the CPU ever could, which means the CPU is way over-tasked when it has to deal with them. That means it spends time doing graphics when it should be reading/writing to files, handling physics and dealing with memory. If software (CPU) rendering were better, then there would be no opengl and no directx. Not to mention the framerates on hardware (GPU) rendering would kick the **** out of the software rendering if it were unthrottled from vsync (which is not a good idea to do either).
In short, linaro is mostly over-hyped and performance increases from it so minimal (and maybe specious) and far between that no one will be able to point and say, "Yes, this part right here when I'm using my phone is running faster due to linaro!" Should developers not use it? If they can, why not, but it's not some holy grail that will make Android trounce every other mobile OS out there on performance.
Click to expand...
Click to collapse
Great write-up.
Linaro can improve app performance about 20% and maybe 100% with app have vsync.
I try a linaro build but can't see different perfomance on launcher and game
meminiau said:
Hey all,
Can someone explain what this Linaro thing I hear about is, and what it means to us Nexus owners? Is it just something that is incorporated into the kernel, our the ROM?
Thanks in advance
Swiped on my Gnex
Click to expand...
Click to collapse
Linaro is an enhanced version of Linux. Linaro was created by cleaning up all the errors in the code that Google didn't apparently didn't want to make perfect. That is what linaro is.
An enhanced version of Linux that was simply cleaned up and recoded.
Thanks guys for the comments!
So Linaro is used in both kernels and ROMs, right?
I have tried lots of ROMs with my Nexus, and keep going back to Blackice. It doesn't seem to be Linaro 'optimised', so what ROMs are?
I saw a thread regarding Franko's Kernel and an offshoot being Linaro optimised, so I will look into that, coz I am already an avid Franko user. Just want to find a ROM that is also optimised this way to try...
any suggestions?
DLD511 said:
Linaro is an enhanced version of Linux. Linaro was created by cleaning up all the errors in the code that Google didn't apparently didn't want to make perfect. That is what linaro is.
An enhanced version of Linux that was simply cleaned up and recoded.
Click to expand...
Click to collapse
Thats not even close to what Linaro is.
adrynalyne said:
Thats not even close to what Linaro is.
Click to expand...
Click to collapse
I don't mean to be rude, but is there any point in your post? If what is being said is not what you say it is, would you mind sharing what Linaro actually is, seeing as that is part of the purpose of this thread?
meminiau said:
I don't mean to be rude, but is there any point in your post? If what is being said is not what you say it is, would you mind sharing what Linaro actually is, seeing as that is part of the purpose of this thread?
Click to expand...
Click to collapse
The reason I posted was to let the poster know that was NOT what Linaro is. The other posts covered it.
I don't appreciate your attitude. Anyone who starts a post with "I dont mean to be rude" fully intends to be rude.
adrynalyne said:
The reason I posted was to let the poster know that was NOT what Linaro is. The other posts covered it.
I don't appreciate your attitude. Anyone who starts a post with "I dont mean to be rude" fully intends to be rude.
Click to expand...
Click to collapse
I just would have appreciated it if at the same time clarifying what isn't correct, that you could have did the same with what was correct.
There is so much info floating around regarding everything, and when someone pipes in and says something is not true, that can make it a little hard to work out what is fact and what isn't.
If you had done this, it would have been a lot more helpful that just a couple words saying someone was wrong. But thanks for clearing up what your thoughts were; that I do appreciate
Related
Hi im running xdandroid on my rhod210 and i am very happy with it, one of the few annoying downsides to it is the ****ty fps of 17.5 which is quite choppy for most 3d games.
But iv heard that gpu overclock for rhodium is definatly possible with the right line added to startup.txt.
look at this thread:http://forum.xda-developers.com/showthread.php?t=697673
it says about overclocking the vogue with a line in startup.txt, with it the vogue achieved 36.5fps!!! which is brilliant, and the vogue is inferior to the tp2 harware wise.
So we know its possible and will give us great improvement, so all we need is someone with the know how to tell us how? it was sais that we would "need to talk to your kernel devs to add this functionality" so hopefully this will be a great update.
any comments, anyone willing to help? anyone working on the xdandroid project willing to implement this? it would be much appreciated.
tank you, please reply :]
Thus far I think we've only overclocked the main CPU, haven't touched the GPU. Looks promising tho.
ohhhhhhhh my god its really ?? i cant belief !! its co0o0o0o0o0o0ol
Jandyman said:
Hi im running xdandroid on my rhod210 and i am very happy with it, one of the few annoying downsides to it is the ****ty fps of 17.5 which is quite choppy for most 3d games.
But iv heard that gpu overclock for rhodium is definatly possible with the right line added to startup.txt.
look at this thread:http://forum.xda-developers.com/showthread.php?t=697673
it says about overclocking the vogue with a line in startup.txt, with it the vogue achieved 36.5fps!!! which is brilliant, and the vogue is inferior to the tp2 harware wise.
So we know its possible and will give us great improvement, so all we need is someone with the know how to tell us how? it was sais that we would "need to talk to your kernel devs to add this functionality" so hopefully this will be a great update.
any comments, anyone willing to help? anyone working on the xdandroid project willing to implement this? it would be much appreciated.
tank you, please reply :]
Click to expand...
Click to collapse
this would be awesome, would definitely raise its quadrant score
I'm not sure what is Vogue and what screen resolution it has, but I supppose as it's old phone with Qvga. Qvga means 1/4 of the pushing pixels that we have on screen. So if Rhodium had qvga screen we would have 4 times beter frame rate. 69 FPS. I wouldn't call 17,5 fps of WVGA 3D ****ty in phone that was presented almost 2 years ago with different operating system. And we should remember that it's Android, which isn't (for now) fully working.
I'm not sure what is Vogue and what screen resolution it has, but I supppose as it's old phone with Qvga. Qvga means 1/4 of the pushing pixels that we have on screen. So if Rhodium had qvga screen we would have 4 times beter frame rate. 69 FPS. I wouldn't call 17,5 fps of WVGA 3D ****ty in phone that was presented almost 2 years ago with different operating system. And we should remember that it's Android, which isn't (for now) fully working.
Click to expand...
Click to collapse
your right the htc vogue has a qvga screen, but it also has less processing power so this should somewhat balence things out. But i still think gpu overclocking would greatly improve the rhodiums performance and if i remember right neoseekers version of android recorded 24.1 fps, and that is without gpu overclock. so improvement is more than possible.
ohhhhhh god 24.1 fbs its brilliant beside 17.5 to the htc rhodium its co0o0o0o0ol
I tried the startup option they were talking about in the thread referenced... if the value is too low then maybe that is the issue, or it just doesn't work. Either way got 17.6fps on neocore before and AFTER changing the startup.txt and rebooting. Unless a dev wants to chime in I don't think that is the only step to overclocking.
Well those startup options are in the kernel. So we'd have to get the kernel enabled before we can ever dream of having the startup option work
Basically any option that's set in cmdline is being passed to the kernel - so if our kernel isn't enabled for that feature/option, it'll just get ignored.
arrgghh beat me to it
i dont kno how hard or easy it is to change the kernal to allow this but hopefully the devs will hear and implement this feature. Or if someone could contact them suggesting it would be great.
its actually simple to over-clock, but does anyone know what values to overclock to before burning up the phone?
If you guys want this done, id look for an existing winmo solution to do this on windows. Once we know what values to use on the clock regs, we can easily port it over on android.
a quick google search of 'overclocking gpu on htc touch pro 2' has lead me to nothing :/ im presuming this is because there is no need to overclock the gpu when running windows mobile because there are very few decent windows mobile games (as far as i kno) and havnt found any using 3d, specially not free.
But if we find the detailed specs of the touch pro 2, and then search for the safe frequesncy to overclock that power of gpu too wouldnt it be the same? thats probly our best bet unless someone can find evidence of overclocking gpu on a tp2 running windows mobile.
Jandyman said:
a quick google search of 'overclocking gpu on htc touch pro 2' has lead me to nothing :/ im presuming this is because there is no need to overclock the gpu when running windows mobile because there are very few decent windows mobile games (as far as i kno) and havnt found any using 3d, specially not free.
But if we find the detailed specs of the touch pro 2, and then search for the safe frequesncy to overclock that power of gpu too wouldnt it be the same? thats probly our best bet unless someone can find evidence of overclocking gpu on a tp2 running windows mobile.
Click to expand...
Click to collapse
Nahh.. don't work that way. Its not like 1 clock you can change to any frequency. All the clocks are derived from the plls and you would need to do some math to determine what pll to use and what to devide it by.
There are also other clocks involved with the display. mddi, mdp are other clocks that can also change. Vogue for example has the ability to over clock mddi.
But yea.. a winmo app would be very helpful.
[ACL] said:
Nahh.. don't work that way. Its not like 1 clock you can change to any frequency. All the clocks are derived from the plls and you would need to do some math to determine what pll to use and what to devide it by.
Click to expand...
Click to collapse
For those who are still unawares at this point, PLLs are crystals on the mainboard that resonate at different frequencies. Thus you would need to tear open the phone and figure out which PLLs are linked to the GPU and which are just ancillary, and then be able to put it back together. Whomever wants to take this upon themselves, I wish them luck.
Hamsteriel said:
For those who are still unawares at this point, PLLs are crystals on the mainboard that resonate at different frequencies. Thus you would need to tear open the phone and figure out which PLLs are linked to the GPU and which are just ancillary, and then be able to put it back together. Whomever wants to take this upon themselves, I wish them luck.
Click to expand...
Click to collapse
Not entirely tru. We know which pll the gpu uses and what its currently dived by. We had this discussion today on the irc board. There is some work being done to help improve the speed.
[ACL] said:
Not entirely tru. We know which pll the gpu uses and what its currently dived by. We had this discussion today on the irc board. There is some work being done to help improve the speed.
Click to expand...
Click to collapse
Yay, I can haz FPS?
[ACL] said:
Not entirely tru. We know which pll the gpu uses and what its currently dived by. We had this discussion today on the irc board. There is some work being done to help improve the speed.
Click to expand...
Click to collapse
Just curious if this work on GPU overclocking ever got anywhere or was determined to be possible in the future?
it's possible - but more than likely it would cause severe problems with battery life and stability. Considering the dismal state of our battery life already I doubt the work is worth it for an extra 4fps in angry birds.
Thread necromancy is bad mkay
randomblame said:
it's possible - but more than likely it would cause severe problems with battery life and stability. Considering the dismal state of our battery life already I doubt the work is worth it for an extra 4fps in angry birds.
Thread necromancy is bad mkay
Click to expand...
Click to collapse
If you're up to date on kernels, especially if you're on Wistilt's test branch, battery life is great. When sleeping, battery life is measured in days now. Anyway, just because the compromises involved don't interest you doesn't mean they wouldn't work for someone else.
Alternatively to overclocking the GPU, I wonder what sort of UI smoothness/framerates would be possible if the display driver were recoded to pixel double to our screen from 400x240 (same resolution as a Samsung Intercept).
I played around with the lcd density but that didn't seem to be able to create the same effect, as program's like Neocore still knew that my display was actually 800x480 and displayed as such.
Extremely Alpha Code
Hey everyone...
I've developed what I think is the first 1.2ghz overclock for the Galaxy tab Sprint ONLY.
WARNING: THIS KERNEL MAY NOT WORK ON YOUR DEVICE, MIGHT DESTROY YOUR DEVICE, MIGHT PUNCH YOUR CHILDREN, I AM NOT RESPONSIBLE FOR ANY DAMAGE CAUSED BY THIS KERNEL, USE AT YOUR OWN RISK
Whew... now that the warning is out of the way I present a 1.4/1.2 overclock based off of the details here:
http://forum.xda-developers.com/showthread.php?t=943669
Quadrant Score: 1129
Linpack Score: 19.29
You will want to unpack the zImage and push it over with Heimdall, while in download mode (hold down power + vol-down until you get the download mode screen).
FOR OTHER DEVELOPERS
------------------------------------------
As I stated before, if you follow the link above and modify the exact same lines you can add this to you kernels as well.. however the file names are different, the files you want to modify are..
arch/arm/plat-samsung/max8998_consumer.c
arch/arm/plat-samsung/s5pc11x-dvfs.c
arch/arm/mach-s5pv210/clock.c
The last one took me forever to grep and find...
This is just the first of many versions, I will look into other CPU frequencies and voltages, lets see how far we can push this baby.
Donate!
V3.3 --- EXT4 ONLY Kernel... only use this if you are on ext4
V3.1 --- Fixed Ext4(?) NOPE
V3.0 --- Based on EA24 Source - untested with older software. Adds EXT4 (broken)
V2.0 --- 1.4/1.2 GHZ OC, reverted previous changes, NO EXT4 (yet..) ONLY FOR SPRINT, USB FIXED - based on koxudaxi's patch
You'll want to use the voltage control app here:
http://forum.xda-developers.com/showthread.php?t=943669
V1.2 --- 1.2 ghz OC, 1.35 Overvolt (for stability), ext2/3/4/rfs
V1.1 --- Added 1ghz back in as a choice, reset your setcpu to select it.
V1.0 --- Added 1.2ghz overclock (replaced 1.0ghz default, will fix later)
would you be willing to do one for us gsm users if we provide kernals for you
Testing now but awesome work!! Works like a charm! I would take it it would run stable about the same speeds as the other Hummingbird processors at normal voltage ( 1200 ) and lower voltages at 1440 just fine but who knows
This is with this Kernel and OCLF.
(LinPack 17.5)
(Quad Score 2369)
(SmartBench 1469 3344)
Damn you, sprint users. . At least there is hope for pushing the Tab now, cheers
How about just setting #define USE_1DOT2GHZ 1 in s5pc11x-dvfs.c and in linux/arch/arm/mach-s5pv210/cpu-freq.c?
That should switch everything to 1.2GHz tables that Samsung nicely prepared for us?
it seems to work for me just fine.
how to update?
Are you sure it works without altering clock.c? Until I changed that file my device was reporting 1.2ghz but it was still super slow.
EDIT: nvm, you're right. Changing that would change clock.c as well. I don't plan on using the default tables, but it's a good place to start if you want to stick to default values. I know this thing can do more than 1.2ghz.
Sent from my galaxy tab
b0ricuaguerrero said:
would you be willing to do one for us gsm users if we provide kernals for you
Click to expand...
Click to collapse
Anyone could do it easily, but I"ll see what I can do. I've gotten ahold of roto's initrd, I just need to grab the source from Samsung. I don't get home until very late in the evening so I can't promise that someone won't beat me to it!
Please, someone beat him to it.
I've never flashed a kernel before, but it worked without a hitch. Thanks!
This sounds awesome, I'm curious if it makes a big difference in performance and how it affects battery life, those of you that use it please post your experiences! Thanks! I know using custom kernels on my N1 makes a huge difference though so I'm hoping this does too...
Looking forward to seeing how much difference this makes, my n900 i clock to 1.2ghz from the default 600 clock (downclocked cortex A7 @ 600mhz default). so pretty sure the tab should do 1.4 or so faultlessly?
Looking forward to GSM revisions, hopefully Roto may even include this in his roms later (well i'm wishing ^^).
Nice to see someone brave enough to start the ball rolling
futuregerald said:
This sounds awesome, I'm curious if it makes a big difference in performance and how it affects battery life, those of you that use it please post your experiences! Thanks! I know using custom kernels on my N1 makes a huge difference though so I'm hoping this does too...
Click to expand...
Click to collapse
Performance increase is definitely noticeable, a lot less lag all around.
Sent from my galaxy tab
had my first lockup with it trying to play 1080p file in vplayer since vplayer don't use gpu to render. But basic video player plays fine just guessing voltage is a little high but who knows still awesome: )
Sent from my SPH-P100 using XDA App
Any word on if this will work for vzw?
I just bought a Galaxy tab and I've never built an Android Kernel before but I spent yesterday tearing through the how-to from the CM guys. I'm familiar with C pretty well, so I was glad to see that I'd be building C and not some Java I'd be totally illiterate to. I'm hoping stepping up to these crazy ARM cores from my usual embedded work with AVR's and 32mhz ARMs shouldn't have too terrible a learning curve.
Anyone who's done kernel building for android before: Is it pretty much a straight forward build process? For some of the embedded work I've done with RTOS systems I've spent days digging through memory maps, linker files and assembly code to trouble shoot issues... Just curious if those will be useful skills for android?
TheCodeBenders said:
Any word on if this will work for vzw?
I just bought a Galaxy tab and I've never built an Android Kernel before but I spent yesterday tearing through the how-to from the CM guys. I'm familiar with C pretty well, so I was glad to see that I'd be building C and not some Java I'd be totally illiterate to. I'm hoping stepping up to these crazy ARM cores from my usual embedded work with AVR's and 32mhz ARMs shouldn't have too terrible a learning curve.
Anyone who's done kernel building for android before: Is it pretty much a straight forward build process? For some of the embedded work I've done with RTOS systems I've spent days digging through memory maps, linker files and assembly code to trouble shoot issues... Just curious if those will be useful skills for android?
Click to expand...
Click to collapse
I actually used the Verizon kernel configuration, since there is no sprint one. I think it should work on Verizon.. make a kernel backup first!
The only difference could be in the initrd but I have no way of knowing until someone tries it.
Bauxite said:
I actually used the Verizon kernel configuration, since there is no sprint one. I think it should work on Verizon.. make a kernel backup first!
The only difference could be in the initrd but I have no way of knowing until someone tries it.
Click to expand...
Click to collapse
You used the .config file? I spent a few hours trying to get a config file setup right.. then u posted which thank you! Lol
Sent from my SPH-P100 using XDA App
The configuration files are stored in arch/arm/configs
There is one for every type of tab
Sent from my galaxy tab
Bauxite said:
The configuration files are stored in arch/arm/configs
There is one for every type of tab
Sent from my galaxy tab
Click to expand...
Click to collapse
Thanks
Sent from my SPH-P100 using XDA App
http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.
I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.
localceleb said:
http://forum.xda-developers.com/showthread.php?t=991276
Found that a couple days ago and was wondering if anyone has tried it or if most developers use something similar as a base.
Click to expand...
Click to collapse
Kernel devs use a released kernel as a base, not a script. A kernel dev worth his salt has already made memory tweaks according to how he feels the system should run. I'm not sure what that script is supposed to fix or how lag and slow draw times are related to memory. Motorola devices are seriously challenged in that department, but HTC's are some of the best out there. I'm not sure where he came up with the idea that no-op IO queuing was as good as deadline. That's couldn't be more wrong. That also makes me question his other tweaks. Basically, if you're running a custom kernel, especially something like the seriously modified ziggy or AOSP kernels, I'd avoid this.
RMarkwald said:
I've tried it with Jermaine151's Minimalist ROM...and honestly I really don't notice any differences with how things run. My cousin, who has the OG Droid, swears by it.
Click to expand...
Click to collapse
Did you get the feeling it was really aimed at Motorola devices, too?
loonatik78 said:
Did you get the feeling it was really aimed at Motorola devices, too?
Click to expand...
Click to collapse
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.
RMarkwald said:
Yeah I did. I kinda figured that running a custom ROM/kernel combo would be ideal instead of running that script, just because the devs have tweaked/maximized their performance already.
I don't know if that's the case with a Moto device, as I have the Xoom but never owned the phone. My cousin swears by it on his OG Droid, and pointed it out to me.
Like you said, I think with HTC devices you won't really notice much, if any differences. I haven't personally.
Click to expand...
Click to collapse
Well, like I said, I'm suspect simply because he thinks no-op is a good IO scheduler. It kinda tells me he doesn't know his ass from a hole in the ground. No-op assumes mechanical storage mediums. Deadline is MUCH better for solid state storage, and all the rest of the schedulers are improvements that may or may not be better, depending on how you use your device.
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
NOOP scheduler is best used with solid state devices such as flash memory or in general with devices that do not depend on mechanical movement to access data (meaning typical "hard disk" drive technology consisting of seek time primarily, plus rotational latency). Such non-mechanical devices do not require re-ordering of multiple I/O requests, a technique that groups together I/O requests that are physically close together on the disk, thereby reducing average seek time and the variability of I/O service time.[2]
Click to expand...
Click to collapse
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
Yes. I'm aware of all that. The shortcoming of no-op is that it doesn't take into account demands of data. Some data should be fetched before other data, thus requiring a re-ordering of requests. It is best used on solid-state devices, but not THE best choice for them, necessarily. One might assume no-op to be roughly on par with deadline if some course assumptions about solid-state are made. No-op would be ideal on the SCSI5 array I built because a storage subsystem controller is re-ordering the data and caching it to memory. The latency times on that memory are exceeding low, as are write operations. In fact, the controller would send write-confirm commands back to the system even before data was actually written to disk to allow for more I/O operations. NAND solid-state is a different creature though. Read latency is certainly fast, however write latency is much, much slower in comparison. Because of this, simply throwing read and write commands at the storage subsystem wastes a lot of time since reads must wait on lengthy writes. Deadline holds significant advantage over no-op because it will suspend writes operations to ensure read request deadlines are met. In short, it mitigates some of the shortfall that comes with the NANDs lengthy write times. That's why I say it's significantly better.
I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop
zeppelinrox said:
I see.
That's very informative indeed.
Perhaps I can determine of a user has deadline available and if so, use that and if not, use noop
Click to expand...
Click to collapse
I've never professed to be a software guy by any stretch of the imagination. I will never be able to do what you and many, many others do with software, code, Linux, scripting... and of that. I just don't understand that stuff. I'm very much the hardware geek though. Column address strobes? Sense amps? I get that kind of talk. Looking at a script? It might as well be in Sumerian.
zeppelinrox said:
I know deadline is better...but not all phones have deadline available.
I'm no guru on the topic and I go by what I read and read threads about the topic.
I don't take credit for the non-supercharger tweaks as they aren't mine and include links that I used as resources.
Yes I do say noop or deadline would be preferred over other common options on most devices. But the main thing is that both would be faster than what most people have configured - cfq.
btw, this thread seemed convincing that noop is performs very well on android
http://forum.xda-developers.com/showthread.php?t=948001
So forgive me for not consulting you first.
Oh, also...
http://en.wikipedia.org/wiki/Noop_scheduler
But then again, you probably would have given me wrong information.
PS. So it seems that you're not all the bright either
Click to expand...
Click to collapse
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.
I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.
bast525 said:
I ran his V6 Supercharger script, Kick Ass Kernel Tweaks, and the 3G turbocharger tweaks in build.prop....
noticed NO difference whatsoever...
Actually, that isn't true. The one thing that seemed to work was the part about making the home launcher "hard to kill", that actually seemed to work. I was having issues with Sense restarting itself, and this alleviated that issue. I noticed that even if I tried to manually stop sense, I couldn't kill it. Two weeks later I removed all trace of the V6 scripts and haven't had any issues since, no idea why, although now I can manually kill the Sense process and have it restart again.
Anyways... no, there was no performance increase whatsoever.
Click to expand...
Click to collapse
I was curious as to the Sense launcher restarting itself, and if this would fix/have an impact on that issue. Thanks for the info!
anyone that gave loonatik a hard time on this site seriously needs to reconsider, this guy knows his stuff.
loonatik78 said:
I forgot... I also wanted to explain that XDA thread a little.
It looks like he's basing his times on sequential writes, reads, then erases. Were that similar to real world use, his results would be valid, but seldom does anything work like that. Without knowing the specific IC of the flash drive in use, certain features of it can only be guessed at. Unless it's a virgin device or written to 0's, chances are writes are also going to come in conjunction with erases, which are a completely different process, and just as lengthy as writes. Because of how NAND works, larger erases and writes can be accomplished much faster by the address block rather than on a file by file basis. This is because NAND can only address blocks at a time. It has no random access capability for pages or bytes, either reading or writing. In short, his test demonstrates an ideal circumstance, one that is RARELY the circumstance of the real world.
Click to expand...
Click to collapse
I did think that the noop result was too good in relation to the other results.
I would not think that it was that much faster (since deadline is better) so I was somewhat surprised.
Thanks for elaborating
On the Sensation, the Supercharger script gave me no speed increase. It did fix my launcher redraws though. The only thing this script helped me with is multitasking, switching between apps constantly was smoother, and more often they didn't get killed by Android's task manager.
On the Nexus S though, it did make a good amount of difference in the operation of the phone.
I think, on the faster phones, like the SGS2 and the Sensation, it only helps with multitasking..
Well I initially came up with it because of the launcher redraw issue... everything else was gravy... well... a whole lotta gravy...
I don't think SuperSmoother sounds as cool so I'll stick with SuperCharger anyway lol
Hello, after running all the kernels currently available for kindle fire, I cant help but noticing that none can clock up to more then 1200mhz. While this is an improvement, I would liek to see a kernel that could overclock all the way up to about 1400-1600mhz. I am sure that the kindle could handle it, It does fine with 1200mhz. Any thoughts, anyone think the kindle could handle this. If so, whats stopping all these great devs?
What a great thread to start. While we're at, here's what I'd "liek" to see: push the CPU to 3 cores. And can we get a higher pixel density, devs? I mean, come on!
My understanding is that no one will release a kernel OC'd to more than 1200 because it's dangerous. Even if some Kindle's can handle it, some can't even handle 1200, and it would cause too many problems with people breaking things. If you want it that bad you'll learn how to compile your own kernel.
This is the development section. Not the Q&A/General. If you would like something, please try it yourself. Remember, everyone does this for free and as a hobby.
What hasoon said...
What Jake said is correct also, it would take waay too much work to get an overclocked kernel stable enough for the masses. Lower frequencies are generally more easily overclocked to higher levels than already high frequencies are.
Plus, why would you even want to overclock, what app/game is it that needs more than our 1.2ghz can handle, especially since we have a dual core cpu? I can't think of any and I have over 900 apps/games.(Not all on my KF, of course)
All it would do is drain your battery faster. Even games like NOVA 2 & NOVA 3(Probably not the most resource intensive games, but you get the point) run fine on 600 and 800 mhz.
Tl;dr:
There would be little to no benefit in furthur overclocking our KF's.
I agree, I use the "Kindle" at a frequency of 800MHz, and I have enough speed for gaming and work)
But that should be added, so this optimization core to increase the autonomy of the "Kindl"
0xD34D had a 2.6x capable of 1.3ghz. Worked well, I had no issues.
If your still stock ROM look it up although some will say it's "dated".
Keep in mind just because it's clocked higher does'nt mean it's faster.
At 1.3ghz it felt OK but benchmarked well below 1.2ghz, something I've noticed on my G-Nex as well. Once over a certain speed performance drops.
Jr member. Hahaha
manchucka said:
What a great thread to start. While we're at, here's what I'd "liek" to see: push the CPU to 3 cores. And can we get a higher pixel density, devs? I mean, come on!
Click to expand...
Click to collapse
PowSniffer0110 said:
Jr member. Hahaha
Click to expand...
Click to collapse
What's the point in posting crap like this other than to be a troll?
Short answer is no, it's not going to happen.
All trolling aside half our devs didn't even want to go to 1.2
Do to differences in device state / hardware race (yes there are some differences in hardware albeit small and not expected by Amazon to be noticeable in stock, that obviously changes when you start changing the OS), there's no way to know who's kindle will support what clock speeds.
If that's not enough for you let's consider that TI clocked it at 1024M for a reason and that any manipulation beyond the MFG specs is going to run the risk of shortening the devices life. You'd get a similar response from me if you are talking real PCs as well. Quite frankly the risks of high OC are not worth the reward, for any device IMHO
Requests go in Q&A (moved)
Pax
FSM Amazon Kindle Fire
Sent from my R800x using Tapatalk 2
any one here can be a "dev" with learning and patience.
if we don't take it upon ourselves then we can't rightly complain with what's available.
with that said i will. i personally do't agree with the argument that it's not good for the device, some can't handle it, etc., so it's not done.
My gnex with the latest faux123 kernel can be set as high as 1.8ghz.
i cant get past 1.35 without a massive hit to performance, same with any other kernel that allow crazy high clock settings. there's a few.
At 1.56ghz it locks up. i don't blame faux123 for the instability at those speeds.
when battery life isn't a concern i'm clocked at 1.35ghz. i won't blame him if the phone stops working either.
I like that he put it there allowing me to try it. it's fun to push the limits. this is about fun.
There's a demand for oc'ing everything. I'd do the same with the KF, although from the 0xD4aD kernel i already know my KF was perfectly stable at 1.3ghz even with uv.
i wish i had the patience but sadly i don't so I wait.
fr4nk1yn said:
i wish i had the patience but sadly i don't so I wait.
Click to expand...
Click to collapse
Interesting irony here
PowSniffer0110 said:
Jr member. Hahaha
Click to expand...
Click to collapse
So many trolls, nothing better to do than stuff his face with donuts, play wow, and TROLL LOL
Sent from my Galaxy Nexus using Tapatalk 2
As pretty much everyone here is aware, there seems to be an obsession with using O3 for compiling binaries for this device. This obsession is probably due to the fact that O3 is the "most optimized" flag in GCC. The issue here is that all of these optimizations do not come without drawbacks.
Technically, due to the nature of the Galaxy Nexus as a mid-spec ARM-based device, we should be using Os to reduce the size of the code that needs to be run.
Also, there are many other drawbacks to O3, such as significantly larger binary size and possible instability, which is why it is not default in the Linux kernel. Binary size does not only impact the size on disk, but can also impact processing time of the code and the amount of space that the program takes in the CPU cache and RAM.
If somebody could please show actual benchmark data showing that O3 optimization actually is an improvement compared to O2 and Os on the Galaxy Nexus, I would really appreciate seeing why it is used on nearly every ROM and kernel.
Edit: I also just read up on Ofast, which disables some standard compliance by simplifying math. I wonder if this would cause any stability issues on the Galaxy Nexus. I'd really like to try -Os -ffast-math when I have time.
I'm sorry, I don't have the time to do that, but I can say this. In all the time I've spent tinkering with compiler optimisations, -O3 has rarely been worth it. Especially on a system like the OMAP 4460 which suffers more from IO bottlenecking than MIPS or FLOPS being the bottleneck. It seems Google's default is -O2 and they have guys who know things about compilers. I would be very curious about -Os though, since that's basically -O2 with the code-bloating features turned off. But I suspect there won't be a perceptible difference.
My guess (again, don't have time to test this) is that since 3 is a bigger nummer than 2, it's used by people who don't know precisely what it does, which seems to be the MO for a lot of people who create ROMs.
borizz27 said:
My guess (again, don't have time to test this) is that since 3 is a bigger nummer than 2, it's used by people who don't know precisely what it does, which seems to be the MO for a lot of people who create ROMs.
Click to expand...
Click to collapse
I also believe that this is the case... I've even seen a ROM on another phone "compiled with O4", which just uses O3 (anything >3 just sets the optimization level to 3)...
During my brief stint in writing patches for Gentoo Linux back when my desktop computer was slower than my phone is now, I read all kinds of weird stuff. People with --ffast-math on complaining that math was wrong, for example, or people on tiny systems calling for complete loop unroll.
The GCC website is quite clear in what the different -O levels do: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options
I would find it very odd someone at Google hasn't had the same idea and actually tested the different Olevels. I'm guesing O2 is where it's at.
borizz27 said:
During my brief stint in writing patches for Gentoo Linux back when my desktop computer was slower than my phone is now, I read all kinds of weird stuff. People with --ffast-math on complaining that math was wrong, for example, or people on tiny systems calling for complete loop unroll.
The GCC website is quite clear in what the different -O levels do: http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Optimize-Options.html#Optimize-Options
I would find it very odd someone at Google hasn't had the same idea and actually tested the different Olevels. I'm guesing O2 is where it's at.
Click to expand...
Click to collapse
Sure, and somebody who worked on Debian, Redhat, etc. also decided on O2 and it had just become a standard for stable, production-ready c builds.
Theoretically, due to the lack of sufficient cache on tiny ARM chips like the omap4, we should try to keep minimal code size through something like Os.
Also, I am assuming that ffast-math has improved because of the inclusion of Ofast in gcc4.6.
I hope to do some testing after I sync AOSP and fix errors with GCC 4.8
MДЯCЦSДИT said:
Sure, and somebody who worked on Debian, Redhat, etc. also decided on O2 and it had just become a standard for stable, production-ready c builds.
Theoretically, due to the lack of sufficient cache on tiny ARM chips like the omap4, we should try to keep minimal code size through something like Os.
Also, I am assuming that ffast-math has improved because of the inclusion of Ofast in gcc4.6.
Click to expand...
Click to collapse
I don't know. The 4460's cache is 1MB. While not huge, it's not tiny by any stretch of the imagination. However, I'm looking forward to your results. We can all keep guessing about what's best, but hard data will be better.
As far as I know, --ffast-math wasn't improved -- it still cuts the same corners and breaks the standard in the same places. -Ofast just combines -O3 with all the standards breaking options like --ffast-math.