[Q] Android with Linaro -- problematic? - Samsung Galaxy Nexus

I have some questions concerning Linaro optimizations. I can't find a ROM ready to run on my Galaxy Nexus so I made my own using Linaro's images (system, userdata and boot) and the result isn't spectacular:
1. no cellular connectivity
2. some graphical glitches -- red bands that surround the display at times
Has anyone made a ROM from their images/source that actually works as it should? I tried their latest AOSP Blob, 71, by the way. Is the 12.08 release better in this regard?
I'm sporting the Android 4.1.1 JRO03R + Linaro kernel ROM from Galaxy Nexus Android Development and I'm getting mixed results:
1. In Antutu I'm getting a maximum of ~6400 points and minimum of ~5400 points while the phone was pretty hot.
2. Quadrant remains relatively consistent during testing, with ~2280 points
3. Velamo (latest) I get ~1300 in HTML5 and ~390 in Metal -- just for reference, I did not test it in CM10 or any other ROM before
The difference between the two benchmarks in weird considering that with CM10 + Franco's latest kernel I get:
1. ~6500 points in Antutu
2. ~2900 points in Quadrant
Any idea why the Antutu scores are so close, while Quadrant is not? It seems odd that one benchmark posts a great improvement over stock that is similar to another ROM while another is quite similar. Benchmarks are not necessarily an indicative of actual performance or feel, but nonetheless provide a reference point and I'm curious about the difference in growth.

Quadrant is a horrible benchmark, never care what it says.
Sent from my Galaxy Nexus using Tapatalk 2

It might be so, but the biggest issue I'm having is with Linaro, not Quadrant.

F_T_B said:
I have some questions concerning Linaro optimizations. I can't find a ROM ready to run on my Galaxy Nexus so I made my own using Linaro's images (system, userdata and boot) and the result isn't spectacular:
1. no cellular connectivity
2. some graphical glitches -- red bands that surround the display at times
Click to expand...
Click to collapse
1- missing gsm binary
2- thats no graphical glitch, that's a feature of android itself when either userdebug or eng variants are built.
suggestion: try to build from their source.
sent from my i9250

Vzw has a linaro release, they are always faster but have some odd quirks. On the incredible it made it tons faster unfortunately this also resulted with random reboots and battery drainage and other odd quirks. I did try the linaro build and only really noticed battery drainage and graphical glitches.
Sent from my Galaxy Nexus using Tapatalk 2

bk201doesntexist said:
1- missing gsm binary
2- thats no graphical glitch, that's a feature of android itself when either userdebug or eng variants are built.
suggestion: try to build from their source.
sent from my i9250
Click to expand...
Click to collapse
1. Thanks, I was guessing towards that but I thought their instructions also covered that. Pretty weird that they don't considering I managed to add the VGA driver by using their scripts.
2. Did not know that, thanks.
I'll see whether it's worth it or not when I'll have the chance. Much appreciated.

Related

[PATCH] As-close-to-stock-as-possible kernel defconfig

Attached is a patch against the E4GT open source release (SPH-D710_Opensource.zip) containing defconfig changes necessary to get a source-built kernel that's as close to stock EG30 as possible. Also attached is a source-built test kernel that attempts to be indistinguishable from EG30 (hopefully same LoS behavior, unrooted, etc.). I've posted this before, but now that it's been tested (at least by daneurysm, thanks!) I figured it was worth making a dev thread so it would have better visibility to the folks most interested in it.
The purpose of this patch is to enable folks to build kernels nearly-identical to EG30, so as to serve as a proper starting point for custom kernel development (admittedly, a good deal of which has already happened). Since it's just kernel config changes, I welcome kernel developers to compare this against your own configs and make any changes you feel appropriate.
Background:
Compiling a kernel from the E4GT kernel sources with the shipped defconfig yields kernel builds that differ quite significantly from EG30. Among the differences, many folks have reported undesirable effects, such as exacerbation of loss-of-signal and other problems. There already exists efforts (e.g., LoStKernel) aimed at eliminating problems like loss-of-signal, but it's a common frustration among developers that what Samsung released as "EG30" sources appear bizarre, if nothing else.
A few weeks ago I posted an inconclusive initial analysis of the source situation, and followed up more recently with an attempt to eliminate all the defconfig changes in the source release in order to either get a kernel as close to stock as possible, if not prove that the kernel source release is bungled.
At this point, I'm uncetain if the source release is actually EG30 or not, aside from that the kernel configuration is definitely not EG30's (which this patch attempts to correct), and there may be some additional modifications to the Westbridge driver. As for the kernel config changes, unmodified source-based kernels include a good deal of debugging options (performance events, profiling support, tracepoints, debugging for preemption, mutexes, spinlocks, etc.) that touch enough of core kernel behavior to plausibly account for the problems folks observe in source-based kernels.
I know chris41g has indepenently implemented a fair number of these kernel config changes already, perhaps exactly those that exacerbate loss-of-signal. Still, for anyone interested in development that wants to "start with EG30 and go from there", this patch may well be of use.
Mirror links:
EG30 fix_defconfig patch: fix_defconfig.diff
Source-compiled, EG30 kernel: kernel-opensource-1.tar.md5
LoStKernel Exp has these changes, thanks mkasick
big ups man, i hope this gets more attention so that more dev's feel comfortable developing aftermarket kernels.
"Sorry, you are limited to 5 thanks a day"
2 days in, running perfectly and so far no LOS at all, which is on par with the stock kernel.
Excellent work, thanks for the effort.
Sent from my SPH-D710 using XDA App
Thanks for this. Will come in handy.
Sent from my SPH-D710 using Tapatalk
Thank you sir! Anyone posting anything development wise for a good base is always welcome and appreciated. Hope Samsung provides and good fix for our next base.
Properly thanked
xlGmanlx said:
big ups man, i hope this gets more attention so that more dev's feel comfortable developing aftermarket kernels.
"Sorry, you are limited to 5 thanks a day"
Click to expand...
Click to collapse
Update: 3 Days running, no LOS and nothing strange happening. Phone is running great. Battery performance is as good as stock, LOS occurance appears as good as stock (like I said, 3 days in and I've seen exactly zero). No strange foreclosures or fruit loops. No funny business at all. On any previous kernel I definitely would have had multiple LOS events by now.
I think you cooked up a winner.
Glad to hear. Thanks for testing it.
mkasick said:
Glad to hear. Thanks for testing it.
Click to expand...
Click to collapse
Mkasick as usual your contributions and knowledge are top notch
Sent from my Nexus S 4G using xda premium
mkasick said:
Glad to hear. Thanks for testing it.
Click to expand...
Click to collapse
No problem at all.
Here is my final update: 7 days in. A+++, would flash again. Not a single LOS in the past week which is right on par with stock in pretty much every way. I'm sure it would go further, but, I've really got an itch to do some flashin'. I'm glad to have helped, but, it's time to move on, lol.
Thanks again. I see no reason why, based on my own experience, this wouldn't become a standard base.
daneurysm said:
No problem at all.
Here is my final update: 7 days in. A+++, would flash again. Not a single LOS in the past week which is right on par with stock in pretty much every way. I'm sure it would go further, but, I've really got an itch to do some flashin'. I'm glad to have helped, but, it's time to move on, lol.
Thanks again. I see no reason why, based on my own experience, this wouldn't become a standard base.
Click to expand...
Click to collapse
Sent from my HTC HD2 using xda premium
LoStKernel 1.0.0.8 includes these configurations changes
Sent from my SPH-D700 using Tapatalk
chris41g said:
LoStKernel 1.0.0.8 includes these configurations changes
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
That may explain the excellent experience I've had with 1.0.0.8 then. Well done guys. Big thanks to you both.
Okay. I finally got off my lazy (and recently very busy) ass and flashed LoSTKernel. While system performance was great (honestly, this phone runs so good stock that I can't tell a difference between stock and heavily tweaked and OC'd) I did notice that my signal bars and signal strength were better on your kernel than LoSTkernel v1.0.2.2
I had sworn that over the past week+ that my signal was looking stronger than usual wherever I went...but I digress....
I checked in all of the random corners of my apartment notable for their terrible (or decent, at best) reception. On the LoSTKernel I couldn't get anything higher than -96db...and that was standing with the phone pressed against the window in the 'hot spot' where with your kernel I got as high as -86db or better. In the "medium" spots where I can typically get -91db to -96db I was getting -101db to -106db on LoSTKernel.
On Starburst with the AOSP 4-bar meter this is a difference of as much as 2 bars with your kernel and zero bars (a difference of as much as 15db) with LoSTKernel in the same exact location.
I didn't have time to verify a difference with speed tests--and they would not be very trust worthy given the nature of radio communications and Sprint's spotty network performance in this area...I did load up facebook and the XDA app a couple times and I'll be damned if your kernel didn't seem noticeably snappier....but once again, anecdotal measures like that are nearly useless.
I'm not necessarily suggesting that your kernel is in fact bringing in a hotter signal somehow...though I wouldn't necessarily rule that out either, as absurd as it sounds. Though perhaps it's something about how your kernel reports or interprets the signal measured and/or how it scales the radio power?
I'm just speculating wildly at this point. When I have more time I'll do some speed tests and try other kernels and see if it's just a fluke with either kernel or not. First thing I'll check is compared to pulled stock and go from there. But, I did notice this and it seems rather significant and worth checking into.
1.0.2.2 is old.. and doesnt include these changes.
try the exp kernel
http://chris41g.devphone.org
chris41g said:
1.0.2.2 is old.. and doesnt include these changes.
try the exp kernel
http://chris41g.devphone.org
Click to expand...
Click to collapse
Okay, first thing. Wow. Nice work. My phone flies. Holds it rocks solid at 1.6ghz perf gov. I can really tell this phone is screamin'.
Okay, before I flashed that took my measurements again to rule out weather, randomness, etc...Then I flashed back the pulled stock kernel and had the same results I had with v1.0.2.2. Then I flashed v1.0.2.2 to make sure it wasn't a fluke. Same. Then I flashed Exp 1.0.0.8 (the latest listed on your site) and I'm still getting the same results.
It might be just my phone, it might be something in mkasick's kernel reporting a wrong number somewhere down the line. I'll stick with v1.0.0.8 for a day or two and see if there is any actual real-world differences. I have my doubts that there are.
...but there is something heavy duty and psychological about having 2/4 bars instead of 0, even if the 3G performance is identical. Luckily my desk at work and at home are in some fringe areas reception wise...so...if there is an actual difference I'll be able to tell over the course of a day or two. A couple places I have to actually aim my phone toward where the tower is to even get data to move....that seems like perfect testing grounds.
Thanks
Warning: Anecdotal evidence ahead.
Okay, LoSTKernel v1.0.0.8 has been a speed demon for me. 1.6ghz perf gov hauls ass and my battery life barely takes a hit....I mean, I don't even notice a difference between 1.6ghz perf gov and 800mhz conservative gov, except in ultra buttery smooth performance. Make of that what you will.
I have experienced 3 LOS since I flashed this 5 days ago. That's 3 more LOS than I got on mkasick's kernel in over a week. Make of that what you will. It's still lightyears better than any other custom source-compiled kernel I've tried.
The signal strength (as measured in db) and "bars" thing I reported on last week remains and seems to apply in all places I've been. However 3G performance has not been affected at all. All of the wacky point-the-phone maneuvers I had to do before to get a signal I still had to do, but, in the fringe signal areas where even on mkasick's kernel I was reporting a -101db signal and getting a -106db instead I still never got kicked to roaming and everything worked the same. Make of that what you will.
I'm only trying to help here....just reporting stuff I've noticed for FWIW, YMMV, etc etc etc.

browser performance

Compared to the other phones I have used I have noticed that browser performance on my GNex seems slow. I have used both stock browser and Chrome. Has anyone else noticed this or have any tips on increasing browser performance? I am using a pretty clean rom (MMuzzy 4.2.1).
+1 this, both the default browser and especially chrome is very slow, I've had better results with third party browsers (dolphin browser, firefox etc.)
Never noticed any problems on my galaxy Nexus. Used cm + Franco. Buttery smooth since day one
Sent from my Nexus 4 using xda premium
I should try Franco kernel. I have never done just a kernel swap before. I'll have to read up on the procedure and any risks.
zephiK said:
Never noticed any problems on my galaxy Nexus. Used cm + Franco. Buttery smooth since day one
Sent from my Nexus 4 using xda premium
Click to expand...
Click to collapse
What other devices have you used for comparison? Comparing to an iphone 4s, which i got for my wife the same time i got my gnex, it is night and day how much faster the browser is.
kineticbits said:
I should try Franco kernel. I have never done just a kernel swap before. I'll have to read up on the procedure and any risks.
Click to expand...
Click to collapse
It won't make a difference.
Sent from my Galaxy Nexus using Tapatalk 2
kineticbits said:
I should try Franco kernel. I have never done just a kernel swap before. I'll have to read up on the procedure and any risks.
Click to expand...
Click to collapse
There really any risks. It's the same process as flashing a ROM.
Boot into Recovery, Wipe Dalvik and Cache, Flash Kernel.
Upon flashing a new ROM, you will need to reflash the kernel after flashing the ROM as flashing the ROM will override your existing kernel with the packaged kernel that comes with the ROM.
What other devices have you used for comparison? Comparing to an iphone 4s, which i got for my wife the same time i got my gnex, it is night and day how much faster the browser is.
Click to expand...
Click to collapse
I have a iPod Touch 3rd Generation (really just use it for music nowadays), Transformer, NS, GN, N4.
The only browsing problem out of those devices I had was my Nexus S where stock browser was laggy but it may of been fixed in 4.0.X. On GB, the experience wasn't very good. iOS browsing is definitely smooth, but I can't bother to use it anymore because the screen is way too small.
I don't use the GN anymore, I gave it to a family member but the browsing has been nothing but exceptional. I can't even choose whether to use AOSP browser (stock on GN) or chrome.
It won't make a difference.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Better than doing nothing. It would make a difference on the overall phone performance that's for sure. Use Trickster Mod with Franco Kernel to customize the kernel in terms of color, sound, frequencies, etc.
zephiK said:
There really any risks. It's the same process as flashing a ROM.
Boot into Recovery, Wipe Dalvik and Cache, Flash Kernel.
Upon flashing a new ROM, you will need to reflash the kernel after flashing the ROM as flashing the ROM will override your existing kernel with the packaged kernel that comes with the ROM.
I have a iPod Touch 3rd Generation (really just use it for music nowadays), Transformer, NS, GN, N4.
The only browsing problem out of those devices I had was my Nexus S where stock browser was laggy but it may of been fixed in 4.0.X. On GB, the experience wasn't very good. iOS browsing is definitely smooth, but I can't bother to use it anymore because the screen is way too small.
I don't use the GN anymore, I gave it to a family member but the browsing has been nothing but exceptional. I can't even choose whether to use AOSP browser (stock on GN) or chrome.
Better than doing nothing. It would make a difference on the overall phone performance that's for sure. Use Trickster Mod with Franco Kernel to customize the kernel in terms of color, sound, frequencies, etc.
Click to expand...
Click to collapse
I highly disagree that using a custom kernel on Android 4.2.1 will make a noticeable difference. It is my humble opinion that Google has optimized this device as far as possible to the point that these third-party developers can't squeeze out anymore performance - if it was possible the Google engineers would have done it themselves.
I use to be a huge Trinity fan, used it since the ICS days and swore up and down by it - now I just run with stock. Do I notice a difference? NOPE.
akira02rex said:
I highly disagree that using a custom kernel on Android 4.2.1 will make a noticeable difference. It is my humble opinion that Google has optimized this device as far as possible to the point that these third-party developers can't squeeze out anymore performance - if it was possible the Google engineers would have done it themselves.
I use to be a huge Trinity fan, used it since the ICS days and swore up and down by it - now I just run with stock. Do I notice a difference? NOPE.
Click to expand...
Click to collapse
By saying that you're implying that NO custom kernel on 4.2.1 on ANY phones it would make a difference. So you're calling everybody a liar in kernel threads because they feel a placebo? It certainly makes a noticeable difference in overall phone performance as well as battery.
Google has not optimized the device as far as possible by ANY means. There are always room for improvement in every device and software that is ever released. As more optimizations are done, it is harder to optimize but there is ALWAYS room for improvement. ALWAYS.
On the Nexus 4, your statement is outright wrong. Google didn't optimize the kernel by any means, there are many problems with it. It is stable for sure, but there is so much Google could of done to improve the kernel where kernel developers are doing quite the job on improving upon it. This goes the same for the Galaxy Nexus as it is the Galaxy Nexus forum.
Colors on stock kernel vs. custom kernel with Color Control... difference? YUP.
Benchmark differences? YUP. (benchmarks dont really mean anything for real-time performance but for some people they are so 'woah' about it)
Improved WiFi performance? YUP. Proved in many threads with newer sources.
Not to mention the PGM module? PGM is so awesome for the Galaxy Nexus that it can't be given up
For me the speed on Stock Android JB 4.2.1 browser is really good but I have issue with uploading:
When I upload files to e.g. xda-developers, ge.tt, mediafire, etc. uploading will fail what have not happened on JB 4.1.2 and older Jelly Bean ROMs.
So if I want to upload file to internet I have to use Chrome.
I use 3G on my Nexus pretty much and the speed is really good compared to other browsers e.g. Chrome, Dolphin.
if there is one thing where the galaxy nexus is really great is browser performance, the stock browser works fantastic, stock or with some custom kernel, the browsing experience is almost the same.. if your browser performance is bad may be your connection or any other issue, because atleast in my case it works perfect.
I just recently switched back to Dolphin after giving Chrome a good month or so to wow me. I don't think it is a lot faster than Chrome, but it is faster. Plus, extensions.
I've used Quick ICS Browser for ages and it's great. Recently started using Opera and it's pretty sweet too, although nut as feature-packed.
Sent from my Galaxy Nexus using Tapatalk 2

Annoying galaxy nexus!!!!

So guys I created this thread because I am very angry! I have on my nexus the latest paranoid Android build and it is annoying as hell. It reboots often and gets so slow that u can't imagine. Can anyone explain that to me. I tried so many things to fix this but nothing really helped. -.- by the way I am on ak kernel purity v30
Sent from my Galaxy Nexus using xda app-developers app
Try a different kernel
Why don't you flash the stock 4.2.2 update. It's fantastic,very smooth, very responsive , and quick. A hell of a lot better then 4.1
ironside2011 said:
Why don't you flash the stock 4.2.2 update. It's fantastic,very smooth, very responsive , and quick. A hell of a lot better then 4.1
Click to expand...
Click to collapse
It's more interesting in terms of new features indeed. Unfortunately is by far more sluggish and buggy than rock stable jzo54k. Scrolling lag that comes after a while take away all the joy of using 4.2.2. It actually made me downgrade to 4.1.2. I've never thought I would admit that but deodexed CNA_3.8.0 feels much smoother and lighter than odexed stock JDQ39 (that feels really smooth right after reboot)
Try latest ak v014 kernel, sounds kernel related, either way that's the best kernel currently for galaxy nexus an more dramatically improve your gnex speed an performance.
Sent from my Galaxy Nexus using xda premium
Franco
Sent from my Galaxy Nexus using Tapatalk 2
Sveke said:
Franco
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
That's what I'm using over clocked at 1.4GHZ running everything smoothly
Why do people keep suggesting switch kernels? With the quantity of people with lag issues, it's definitely AOSP related. All switching kernels will do is sometimes wipe cache and dalvik or the users usually wipe cache and dalvik which supposedly helps for a bit along with the reboot which definitely helps for a bit. Custom kernels may help performance a bit but they don't clear whatever's happening in the code that causes the issue for many?
tiny4579 said:
Why do people keep suggesting switch kernels? With the quantity of people with lag issues, it's definitely AOSP related. All switching kernels will do is sometimes wipe cache and dalvik or the users usually wipe cache and dalvik which supposedly helps for a bit along with the reboot which definitely helps for a bit. Custom kernels may help performance a bit but they don't clear whatever's happening in the code that causes the issue for many?
Click to expand...
Click to collapse
Its probably not directly AOSP related or else every single android device would have the issue on an AOSP ROM.
If I had to guess I'd say that people just aren't maintaining their phone. They let garbage data build up in the internal storage, collect tons of apps that they almost never use and almost never reboot. With just a little upkeep I've had almost none of the issues people are complaining about and when I did it was gone as soon as I did some tidying up.
I mentioned it very often now in different thread as it seems a very common issue - did you try lagfix from PlayStore? This helped me.
http://forum.xda-developers.com/showpost.php?p=39273944&postcount=21
Not a final solution, but it works (for some time) and I hope Google fixes it in Android 5...
hudl said:
I mentioned it very often now in different thread as it seems a very common issue - did you try lagfix from PlayStore? This helped me.
http://forum.xda-developers.com/showpost.php?p=39273944&postcount=21
Not a final solution, but it works (for some time) and I hope Google fixes it in Android 5...
Click to expand...
Click to collapse
Actually it fixed my all problems related to performance
I had these slow down problem too for almost 2 months because my available storage was too low (around 1gb).
Then I realized that its related to trimming problem.
So far the combo of lagfix and seeder is working good.
No lag n other problems at all
Sent from my Galaxy Nexus using xda premium
063_XOBX said:
If I had to guess I'd say that people just aren't maintaining their phone. They let garbage data build up in the internal storage, collect tons of apps that they almost never use and almost never reboot. With just a little upkeep I've had almost none of the issues people are complaining about and when I did it was gone as soon as I did some tidying up.
Click to expand...
Click to collapse
It can be very true. However I use my device in exactly the same way I used to do while running previous versions of JB. I have installed the almost exactly the same amount and sort of apps. I try to keep my gnex clean. I've never had less free memory than 4 GB. To be honest I don't remember when I had to reboot my nexus before 4.2.2 was released cos I've never had this low fps scrolling issue until JDQ39. I am not trying to advertise any rom. I've always been huge fan of stock due to its stability and smoothness, but Purity Rom was the only one I haven't noticed this bug so far.
No response from Thread creator, he is no care with our comments...lol..
Sent from my Galaxy Nexus using Tapatalk 2
i'm using Rootbox, it's amazing!

[Q] Why are TW ROMs so much faster than AOSP ROMs?

I've been using Android for years now and I'm a huge Linux geek, but does the TouchWiz kernel really make that much of a performance improvement over an AOSP kernel, or is it other things also? When I first got my S4 I was amazed at how fast TW was out of the box, I stuck with it a few days and then went on to AOSP roms. I stayed on AOSP roms for about a week or two and things started to feel slower.
(before anyone flames me, I know benchmark scores don't mean a lot but they are a decent performance measurement) Just for the hell of it I ran Quadrant Advanced OC'd to 1.9 GHz and got a max of 7,000; I was having call quality issues to I decided to switch back to a TW rom, I was using either Wicked or Infamous S4 and while I had it loaded I ran Quadrant and got a whopping 12,700 which blew my mind! After the GE rom came out I was running that for about a week and was getting the same score. I didn't test it on the 4.3 leak though, which is apparently AOSP and not a stripped down TW rom.
So what is it about TW based roms that accounts for the huge difference in performance? Not only are my benchmark scores about 5,000-6,000 points higher, it also feels snappier while opening up programs and changing orientations. Are there a bunch of drivers/kernel modules that are missing or are hacked together in the AOSP roms/kernels that aren't nearly as good as the ones in the "official" roms?
Actually that is not true, I have seen some fast aosp roms out there, it is kernel related, experiment with a different kernel, you will see the results change.
brando56894 said:
So what is it about TW based roms that accounts for the huge difference in performance? Not only are my benchmark scores about 5,000-6,000 points higher, it also feels snappier while opening up programs and changing orientations. Are there a bunch of drivers/kernel modules that are missing or are hacked together in the AOSP roms/kernels that aren't nearly as good as the ones in the "official" roms?
Click to expand...
Click to collapse
I wouldn't say they're missing or hacked together, but Samsung has all the sources for their devices. Not just the kernel source, but also all the inner workings of the SoCs they're programming for. They have all the information needed to maximize the performance of the devices the make. AOSP roms don't have this luxury.
Think of it like graphics drivers in the Linux world. You can use nvidia's driver blobs (TW roms), or you can use F/OSS developed Nouveau drivers (AOSP).
TheAxman said:
Actually that is not true, I have seen some fast aosp roms out there, it is kernel related, experiment with a different kernel, you will see the results change.
Click to expand...
Click to collapse
I never said that it happened on all of the devices that I've had. In most cases the AOSP roms were almost always faster.
Toleraen said:
I wouldn't say they're missing or hacked together, but Samsung has all the sources for their devices. Not just the kernel source, but also all the inner workings of the SoCs they're programming for. They have all the information needed to maximize the performance of the devices the make. AOSP roms don't have this luxury.
Think of it like graphics drivers in the Linux world. You can use nvidia's driver blobs (TW roms), or you can use F/OSS developed Nouveau drivers (AOSP).
Click to expand...
Click to collapse
Yea I figured it was something like that. Thanks. Boo for closed source stuff
Just for fun I'm going to keep a running tally of quadrant benchmarks in here.
Score: 7762
Rom: RevoltJB v4.4 Stable
Kernel: Chronic Kernel 3.4.50 7/2
CPU: max 1.89 GHz performance governor
GPU: 504 performance governor
Score: 13191
Rom: Infamous S4 Google Edition v3
Kernel: Ktoonsez 3.4.0-KT-SGS4
CPU: max 1.998 GHz performance governor
GPU: 504 MHz performance governor
Quadrant scores mean absolutely nothing in terms of how fast a ROM/kernel is. You're basically using a random number generator to base your idea of speed on. TW ROMs are slow as hell when compared to AOSP.
task650 said:
Quadrant scores mean absolutely nothing in terms of how fast a ROM/kernel is. You're basically using a random number generator to base your idea of speed on. TW ROMs are slow as hell when compared to AOSP.
Click to expand...
Click to collapse
Bench marks aren't completely useless or else companies that review tech products wouldn't use them at all (I'm not speaking necessarily about Android). They do vary by a few hundred points but they do give you a ballpark range. Have you tried out the Google Edition rom yet? It's easy faster than any AOSP rom I've ever used.
Sent from my SGH-M919G using Tapatalk 4 Beta
I've been using the GE ROM since it leaked and my phone runs circles around my brothers TW galaxy s4. *shrugs
Sent from my GT-I9505G using xda app-developers app
fuego77 said:
I've been using the GE ROM since it leaked and my phone runs circles around my brothers TW galaxy s4. *shrugs
Sent from my GT-I9505G using xda app-developers app
Click to expand...
Click to collapse
I don't have another one to test against, but they feel equally fast to me.
AOSP and AOKP ROMS are by far much smoother. I believe its to do with the lower size of the OS, theres just much fewer processes, and not as much detailing in the menus which just creates smoother overall transitions and a good experience. My only crutch against them are that they heat my Galaxy S4 so much, and i don't know why it would be so, but on TW my device can idle in the 30's, heats to 40's/50's under medium-heavy load and goes up to about 65 when gaming for long periods of time.
On AOKP and AOSP in the same situations i wont ever idle below 50 degrees, moderate usage brings it to mid-high 60's and heavy usage it constantly throttles at 70, and when i disabled my throttle it heated up to 80 so quick that i got scared and quickly turned it back on. All these temps are in C.
I found on the Galaxy S3 that AOKP ran much cooler than it did on the S4, and its just the temps on those ROMS are what keeps me on Touchwiz as my daily driver. Its bad on the battery life and bad on the feel when your phone is warm no matter what you do, yet i love the whole neatness and smoothness of AOKP.
Monkz said:
AOSP and AOKP ROMS are by far much smoother
Click to expand...
Click to collapse
That's not what I've experienced on my S4. The Google Edition (which is TW based) runs circles around Carbon and RevoltJB, I haven't tried pure CM or AOKP yet though.
I*experimented the same problem concerning performance and high temperature on S4 on AOSP*roms.
I opened a issue on CM (CYAN-1768) and SlimRom (SlimRoms/device_samsung_jfltetmo/issues/2) issue tracker.
schumnana said:
I*experimented the same problem concerning performance and high temperature on S4 on AOSP*roms.
I opened a issue on CM (CYAN-1768) and SlimRom (SlimRoms/device_samsung_jfltetmo/issues/2) issue tracker.
Click to expand...
Click to collapse
Because people do not know that ODEXING a ROM optimizes it. Most members see "deodexed" on the title of the zip and believe it will be faster than odex version. *sigh*
But none of them are faster than the new LiquidSmooth rom it's blazing fast. I have used it on my S2 and S3 but this is the fastest aosp rom out easily.
Sent from my SGH-M919 using Tapatalk 2
I'm on tasks AOKP and its really fast. Every aosp ROM in general I have tried are faster.
I have never seen an aosp rom be "faster" than stock, and that's on all my phones. I used to like cm/aokp but they always have bugs, whether it's small or big, they always have bugs. On the S3 and on the S4 I have flashed aosp roms but always end up coming back to tw. Tw>aosp
Sent from Flip's Galaxy S4
richardlibeau said:
But none of them are faster than the new LiquidSmooth rom it's blazing fast. I have used it on my S2 and S3 but this is the fastest aosp rom out easily.
Sent from my SGH-M919 using Tapatalk 2
Click to expand...
Click to collapse
whytechapel_x said:
I'm on tasks AOKP and its really fast. Every aosp ROM in general I have tried are faster.
Click to expand...
Click to collapse
These are 2 very very fast roms... best aosp roms ive used. But, bottom line, samsung has stepped their game up and made tw work like a custom rom itself. Aside from the 600mb+ of stock bloat, this phone is perfect out if the box
Sent from my SGH-M919 using Tapatalk 2
DigitalUnderground said:
These are 2 very very fast roms... best aosp roms ive used. But, bottom line, samsung has stepped their game up and made tw work like a custom rom itself. Aside from the 600mb+ of stock bloat, this phone is perfect out if the box
Sent from my SGH-M919 using Tapatalk 2
Click to expand...
Click to collapse
Say what??? Perfect out of the box no way.. and the tw theme it comes with is terrible looking as well.
richardlibeau said:
Say what??? Perfect out of the box no way.. and the tw theme it comes with is terrible looking as well.
Click to expand...
Click to collapse
Lol ok
Sent from my SGH-M919 using Tapatalk 2
DigitalUnderground said:
Lol ok
Sent from my SGH-M919 using Tapatalk 2
Click to expand...
Click to collapse
I mean l love the phone how I have it now but I guess to each his own. TW just doesn't work for me. The best TW rom I have seen that is themed and looks gteat is DeathStar but that's just my opinion. Personally I have never kept a stock rom on any phone I have ever had because of the limitations with it and the usual stock bull that comes with it.
Sent from my SGH-M919 using Tapatalk 2
richardlibeau said:
I mean l love the phone how I have it now but I guess to each his own. TW just doesn't work for me. The best TW rom I have seen that is themed and looks gteat is DeathStar but that's just my opinion. Personally I have never kept a stock rom on any phone I have ever had because of the limitations with it and the usual stock bull that comes with it.
Sent from my SGH-M919 using Tapatalk 2
Click to expand...
Click to collapse
I always use custom roms as well... usually the ones i cook myself (see sig) but I'm just saying that there aren't as many mods or whatnot to add to this phone because of how nice it is on stock. Like u said... to each his own.
Sent from my SGH-M919 using Tapatalk 2

[Q] Questions about Galaxy Nexus slowdowns and Linaro...

Howdy,
I'm new here, so go easy on me.
So I just upgraded my stock Galaxy Nexus to CyanogenMod 10.1 and I noticed that the kernel was still at version 3.0.x. At the same time, I see that there are newer Android kernels, and my understanding is that Texas Instruments had some folks working on that 3.0 kernel that made it work well on the OMAP chip in the GNex, but TI has given up on phones, leaving the Galaxy Nexus' OMAP architecture somewhat abandoned when it comes to phones. Everyone keeps saying that TI abandoned OMAP and that the Galaxy Nexus is stuck at 3.0 forever.
In particular, support for SSD 'TRIM' on dm-crypt volumes was added in kernel 3.1. That's a big deal if you encrypt your phone and it starts crawling sooner than it should because your slack can't be trimmed.
So, being not a stranger to Google and git trees, I went searching around. I have a few questions:
1. It appears that the OMAP magic lives on and gets updates in the form of Linaro's offerings. Could their kernel be brought into CyanogenMod (or any other modded ROM)?
2. Are the Linaro Galaxy Nexus builds actually usable on its own? Can I just follow their instructions and have a working usable system in a few hours?
3. Assuming that the Linaro builds are mostly development or barebones, and that their kernel works on the Galaxy Nexus, are there any fully-polished ROMs out there that run Linaro-based kernels?
4. Assuming 'no' to 3 and 4, can I pop ONLY a new kernel into an existing CM install, or will that Break Things Horribly?
I've learned from your question that The makers of our chipset has stopped supporting it ,and for me ,this news would make me upgrade to another phone
Thanks
tarekh020 said:
...The makers of our chipset has stopped supporting it ,and for me ,this news would make me upgrade to another phone
Click to expand...
Click to collapse
But why should that matter? If the source for the 3.0.31 kernel with the 'tuna'-specific stuff is out in the open, and Linaro is keeping the ball running witht he overall OMAP subarchitecture, then shouldn't it be relatively simple to keep pushing the customizations from 3.0.31-tuna up into newer kernel versions?
There are also some binary bits and pieces available from Google for this phone, but I think it would be worthwhile to see 'how far they go' as far as kernel versions.
I mean, normally I'd understand leaving the Galaxy Nexus at 3.0.x, but there's a BIG BUG with regards to the dm-crypt layer not passing TRIM commands to the flash that turns the phone into a slug after a while, and the bug is fixed in kernel 3.1 and up.
mangeek said:
But why should that matter? If the source for the 3.0.31 kernel with the 'tuna'-specific stuff is out in the open, and Linaro is keeping the ball running witht he overall OMAP subarchitecture, then shouldn't it be relatively simple to keep pushing the customizations from 3.0.31-tuna up into newer kernel versions?
There are also some binary bits and pieces available from Google for this phone, but I think it would be worthwhile to see 'how far they go' as far as kernel versions.
I mean, normally I'd understand leaving the Galaxy Nexus at 3.0.x, but there's a BIG BUG with regards to the dm-crypt layer not passing TRIM commands to the flash that turns the phone into a slug after a while, and the bug is fixed in kernel 3.1 and up.
Click to expand...
Click to collapse
Most kernels out right now like ASKP, Franco etc...are based on 3.0.8X. The Gnex isn't stuck on 3.0 either. One of the kernel devs has gotten 3.4 working but a kernel was never released, and there are also apps and scripts that force TRIM so I don't think it's much of an issue but I don't know much about kernels and stuff anyways...
Sent from my Galaxy Nexus using Tapatalk 4 Beta
bmg1001 said:
Most kernels out right now... are based on 3.0.8X. The Gnex isn't stuck on 3.0 either. One of the kernel devs has gotten 3.4 working but a kernel was never released, and there are also apps and scripts that force TRIM so I don't think it's much of an issue but I don't know much about kernels and stuff anyways...
Click to expand...
Click to collapse
It's simple to overlay 3.0.31+ on top of 3.0.x to get 3.0.85, etc., but those only provide minor bug fixes. The part that needs to get into the Galaxy Nexus is from 3.1 or newer, where dm-crypt has a 'discards' option that allows encrypted volumes to TRIM.
As it stands now, encrypted volumes can't TRIM, not even with third-party utilities. TRIM exists to free-up large contiguous blocks of zeroed writeable space, and the dm-crypt in 3.0.x writes encrypted gobbledygook to the entire volume, even empty space. That means that write performance on an encrypted Galaxy Nexus is -always- bad and can't be trimmed.
As for the 3.4... There are Google experimental 3.4 and 3.8 kernels, but they're for newer devices and don't seem to include the various bits-and-pieces that the TI OMAP team added to get the Galaxy Nexus running.
Someone needs to either backport newer versions of dm-crypt to 3.0.x and enable discards by default, or they need to move the Galaxy Nexus-specific code up to newer (3.1+, not 3.0.31+) revisions of the kernel. I prefer the latter, as it would yield many other benefits as well.

Categories

Resources