yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] knzo:
I'll just come out and say it: seems fishy.

I've seen you obsessed before at some kernel "myths" like thalamus claim that latest mainline updates were hurting performance/battery and to be honest I don't see in these studies a sufficient amount of rigor, objectivity and data to withdraw any conclusions except your clear agenda against some things that are said.

For example, some flaws:

1. 0xBenchmark and AnTuTu only measure one kind of performance, you may think you are gauging something when you're not.

2. A more recent toolchain supposedly provides improvements in other areas which weren't taken into account.

3. Such benchmarks have fluctuations, they are not particularly accurate.

4. The LCD undervolt test lacks data results (we are to believe your word?) and the methods chosen aren't good - too many parasite variables.

5. Again, vague information (you don't specify which debugging was removed). Not to mention some debug are proven to hurt performance like Frame Pointer. If you're going against theory, one more reason to be concise.

6. And once more, removing debug/crap should improve other things which were completely ignored (mm, pm, etc).

7. The last test just doesn't make sense, there are too many things involved to be that linear.

8. Why do the screenshots have battery % and the galaxy nexus keys if you were on OTA JRO0E?

Long story short, I can't really bring myself to take this too seriously as it lacks data and there's just too much hate undermining the credibility of the post. I should also mention that I don't have a position regarding each of those claims; I believe we should experiment, analyse, collect feedback and withdraw conclusions for everything but this just didn't convince me, especially when it comes to your neutrality. Thanks though.
[Nexus S Android Development] anshumandash:
I guess I know whom you are talking about, but may be you have not read his latest thread. lol...

When this dev released his .39 kernel, I asked how does it impact the battery. He shouted back at me in a rude voice saying Kernels doesn't impact battery and it is only the ROM. Fare enough.

But today he claims around that merging in to mainline from .31 to .39, .40 etc drains more battery and he is going back to .31 and says he has data etc.

I am glad this test has proved it actually doesn't matter.
[Nexus S Android Development] _thalamus:
I said generally, which is correct. The vast majority of the time the kernel has nothing to do with battery drain.

And yes, merging mainline does make a difference.

If you actually bother to read my blog post, you will see I don't actually mention battery drain at all as my reasons for ditching mainline updates.

Personally, I don't use the Nexus S enough to notice increases / decreases in drain, it's my development phone. However, quite a lot of users *have* told me that they have noticed improvements since I rolled back. Perhaps they are all wrong too?

It's not wakelocks, it's not obvious drain, it's subtle increases in drain which are impossible to track down.

However, In the case of the GNex when I merged to .40 I got 6% an hour drain, but when I went back to .31, I got less than 1% an hour drain. Merging back up again gives me the 6% an hour drain again with *nothing* else changed. It doesn't take a genius to figure out that it must be the kernel merging which has caused it, or is someone going to argue with that too? Lol.

I'm not entirely sure what myths have been busted here. It seems like a non kernel developer wasted their time to prove utterly nothing, which amuses me slightly. Do you honesty think I apply any modification, tweak or anything without testing the impact? If it makes no difference, it doesn't go in.

Removing unused stuff is simply to make the compile slightly quicker and the resulting zImage smaller. I don't believe there are any performance improvements to gain by doing that, but what is the point having junk built in which isn't needed?

As for removing all debugging, it's not a good idea, because how are you going to get a stacktrace if you panic? Again, that is something I won't do, and I know it makes little difference.

Anyway, if you want to test more accurate real world usage, use the 2D tests on 0xBench. They are CPU bound and they are greatly affected by small changes. Here are some I did a few weeks ago to test the best toolchain for the Nexus 7.

As you can see, there clearly is a difference between the speed of code that they produce. Raw speed is one thing, but graphics benchmarks more accurately represent real usage.

tl;dr: Ignore the agenda driven opinions and dubious results in the first post, they are meaningless.
[Nexus S Android Development] atl4ntis:
Performance, 1000.

If you read carefully i tested the battery with daily use aswell.

Quoting myself : " Also with standard usage, with data always on and few wifi and standard usage managed to reach 36 hours on same charge..

If you read carefully the test is inspired by the Ezekeel one, that's why i used the same tools/approach. I do thrust his work more.

After tons of test around the web can pretty much assure you that toolchains may give something good compiling the OS ITSELF not the kernel.

This is a rude attitude. Why don't you explain why the methods are wrong?

If after days of testing with almost just the lcd on, seeing wich charge lasted longer isn't good feel free to explain why.

Maybe i should've used a tester?

I simply want to see if my phone last longer with lcd undervolt, simply.

About data results: the results is around 5%, would it better if i wrote how much every % lasted and then making simple math operations? No thanks.

i don't like to edit OP posts so i'll write it here. Quoting myself:

What i came up with is something like 5%, that means something like 10 more screen time with standard use, even less, and considering this small margin, can also be unrelated at all to the undervolt.

i meant 10 minutes more screen time

I disabled them one by one aswell and never noticed an increase performance. So your statement is wrong. I don't have the config anymore but for sure kernel, slub dm and cgroup subsys were disabled.

I develop my own rom and kernel just for myself. I make these tests for myself not to prove anything, i'm just sharing.

These tests took me one week to be made. Do you really think i would ruin them posting wrong informations or ruining my reputation?

Actually i was surprised by some of them.

You're welcomed to made them again or better since you didn't like the methods.
[Nexus S Android Development] _thalamus:
That single sentence sums up this entire thread.

Basically, you started these tests with an agenda which was to validate ezekeels tests and you 'proved' what you wanted to prove to fit your agenda.

Anyone can do that. It doesn't actually prove anything though, it just generates FUD. Congrats.
[Nexus S Android Development] atl4ntis:
No just one test and just becouse similar test were made.

Go troll somewhere else.
[Nexus S Android Development] _thalamus:
I'm not trolling. I'm rightly questioning your extremely dubious results and the fact you have an agenda, which you clearly do. If you don't want people to question them, perhaps go and post them on Rootzwiki instead where they will be blindly accepted as gospel.

The definition of trolling is here.

Your post is simply confusing users and generating FUD, but perhaps *that* is your true agenda, is it not?
[Nexus S Android Development] atl4ntis:
If you think these tests are wrong just provide some proof instead of offending people or talking about agenda or even worse reporting them as wrong because "other people said so" instead of testing them by yourself or saying some issues are not trackable.lol.

Some moderator should get rid of this thanks.
[Nexus S Android Development] bedalus:
I think the OP has good intentions and had shown aptitude in collecting data, which deserves praise.

Just because something isn't perfect in the first attempt doesn't mean it deserves to be torn down.

Efforts like this need to be carefully nurtured because they go towards dispelling the prevalent aura of general guff that is spouted here in the development section on a daily basis.

To improve the study, make sure you are clear about the test conditions, and run the same test repeatedly until the mean and median converge to within some acceptable tolerance, e.g. 1%

You can then use standard deviation to make accurate statements about the data including its variability.

If you run multiple benchmarks you can later do regression testing to eliminate the tests that aren't correlated to the end result. You can combine the results of multiple benchmarks using the geometric mean.

If that's confusing, then I'll happily explain it in more detail. :)
[Nexus S Android Development] Andy:
Any more shenanigans, this thread gets locked. Either discuss the post like an adult or don't post.
[Nexus S Android Development] albundy2010:
You quoted my post about battery screens + on screen buttons but have not answered what is the deal with it.

What are those on screen buttons doing there on a official ROM for the 9023?
[Nexus S Android Development] atl4ntis:
Already answered but maybe i wasn't clear enough.

I tested those kernel with daily usage aswell, that mean with mods apps and every crap i use daily. Those ss refers to the daily usage with my rom.
[Nexus S Android Development] knzo:
That's a fair question. I'll tell you how I'd do it in order to reduce parasite variables and you can infer why I think your methods weren't the best:

Fully charge the phone. = homogeneity (they all start from same position)

Airplane mode. No sound. Max brightness. = remove parasites from daily usage fluctuations (different sync, oscillating wlan/network signals, volume and so on)

Play a video of at least 1 hour on performance, 1000. = approximately the same CPU load (one less parasite) for the determined duration.

When it ends, take note of battery %.

(Overkill) - Wipe battery stats before each test & remove battery and then make sure that after both tests the battery graph displays similar % on everything except the screen. = reliability

(Overkill) - Use a tool like BetterBatteryStats to check for wakelocks after the test (parasites). = reliability

Even with this there are still other stuff that can't be controlled. However, this seems like a good point to start so perhaps I may just do it this afternoon.
[Nexus S Android Development] atl4ntis:
You obviously didn't read the "how i did the tests" part since i did at least 5 of 6 of what you're writing now.

Also my question was for the lcd one. Still missing an answer.

EDIT:

Quoting myself:

Additional notes:

The system is booted up once, every tutorial is closed, 0xbenchmark, Antutu and Screen Timeout Toggle are installed,

airplane mode is toggled

, system is rebooted in recovery,

battery stats are deleted, cache and dalvik are cleared

, system is nand backupped.

Every test starts after 30 min of phone off to let him cool, restoring the nand backup and waiting 5 min after system is booted up. Phone is connected to A/C charger.

Kernel are swapped after the nand restore.

<snip>

..let phone fully charge, boot it up, put max brightness...

Seriously....

Then about the other argument about my hate or my biased opinion or better my obsession, you clearly missed how the things went. I said i made tests regarding the infamous battery drain issue, got flamed, hate spreaded, posted result. How could my tests be biased since the hate happened later? You can search my posts, aint that much.

Also would thank bedalus for his words and suggestions. I respect very much his works.
[Nexus S Android Development] albundy2010:
You should have made that more clear. When you say your ROM You're talking about factory images + plus whatever mods you applied etc. At that point they are not factory images any more.

When you state you tested with factory images from Google people are going to assume they are untouched. And that your daily usage settings would include apps and settings but nothing that changes the actual ROM itself.

It wouldn't affect your results since all kernels are tested against the same rom. It just added confusion by the way you worded it. When you say factory images , people are always going to assume it is actually running stock untouched factory images.

Thanks for clearing that up!
[Nexus S Android Development] atl4ntis:
I used stock images with no additions nor mods for all the benchmarks and so on.

I then used my rom just to test daily usage to see if drain could occur on phone use instead of idle time.

And yes, results would've been the same anyway.
[Nexus S Android Development] knzo:
You're focusing on the environment control variables and not on the measure itself which is what I find faulty.

And yes, the post is full of hate undermining your credibility, you just have to look at the pink quotes to get a grasp on your mockingly position. The lack of data also doesn't help as I don't see any palpable results, I see words and useless benchmarks and I don't like those when withdrawing conclusions. I prefer unanimous and collective feedback along with solid numbers convergent with other findings.

Don't take what I'm saying as offensive or discouraging though as even when I'm reading peer-reviewed articles in my expertise area I only take them into account if they gather the following conditions: a) bulletproof design, b) multitrait-multimethod matrix, c) replicated. So as you can see I'm demanding by nature. ;)

Anyway, enough posting for me.
[Nexus S Android Development] atl4ntis:
^^ pink quotes are meant to be funny and are part of the myth busted joke.

Waiting for your afternoon lcd test.
[Nexus S Android Development] knzo:
I'll post the results tomorrow or so.

But assuming the null hypothesis is the inexistence of a significant effect then my money is not on infirming it!
[Nexus S Android Development] sysadmn:
I would be interested in seeing the raw data. If you have 10+ runs for a test you can begin to determine whether the results are statistically significant (30+ is better, but...). An average result hides the variability between individual runs. Thanks.
[Nexus S Android Development] knzo:
As promised, I have made a simple test of my own to test if the LCD undervolt does actually have a significant effect. This change is one that mathkid95 (matrix), r_data (Air), myself and probably others have done in the kernel. Even though I was somewhat skeptical about it, I decided to include it for experimental purposes (after conducting a proof of concept and having it changed to 1.5V to see if my phone booted - didn't) and up to this day I hadn't reached a conclusion if it in fact helped.

Environment control:

Airplane mode

No sound

Max brightness

Reboot before each test

Kernels used: latest thalamus + 2.3V UV patch && latest thalamus

CPU load via Suits episode

Method:

Wait until phone is fully charged (94% in mine)

Unplug and play latest episode of Suits in MX Video Player (42m30s)

After playback, take screenshot of battery menu

Check BetterBatteryStats for wakelocks and other unwelcome stuff

Results:

2.3V: http://bayimg.com/JaBnbaAeh

3.0V: http://bayimg.com/JabncaAEh

There doesn't seem to be any other heavy parasite judging from the data in BetterBatteryStats and in the battery menu (as you can see in ss). Even though this design may be flawed in some aspect or proved to be not reliable as emulating daily usage, it's enough for me wanting to revert it since it seems completely useless.
[Nexus S Android Development] :
That result doesn't surprise me in the slightest. I'm glad that one has been put to bed, I always believed it was utter garbage so didn't even bother testing it.

I don't know a great deal about LCD panels, but I suspect that the panel does it's own voltage control for brightness adjustments, so the voltage that the regulator powers the rail with will be significantly higher than the voltage which is driving the backlight or LEDs in the case of AMOLED. So basically, unless you lowered the rail voltage to something stupidly low, the LCD won't care and will continue working as normal, consuming exactly the same amount of power.
[Desire HD Q&A, Help & Troubleshooting] uniznguyen:
Do we have a backup tool in Android platform like Ghost or Partition Image in Windows? I wanna try some new ROMs but still wanna backup the old rom which havs so many tweaks so I can roll back to the old rom just in case
[Desire HD Q&A, Help & Troubleshooting] uros0104:
Erm, Clockwordmod recovery? Backup option?
[Desire HD Q&A, Help & Troubleshooting] Reinaldo33897:
4ext recovery backup and restore tab

Sent from an Ice Cold Inspire 4G
[Galaxy S III Accessories] japjit100:
Today I purchased flip case copy from local market

Only for 6 dollars

It replaced back like original
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] Papaniz:
Hi,

last night this problem just came out of nowhere. I was texting and calling fine like hour before I noticed it happen, but whenever I try to call it hangs up, and whenever I try to text it tells me to try again when service is available. On the lock screen it tells me "Emergency Calls Only", but sometimes it shows "Virgin" I'm with Virgin Mobile Canada, but still doesn't work. I've tried the following:

1. Pulling out battery and putting it back in.

2. Nandroid restore to when I first rooted it, and when it was working fine.

3. Take out SIM card, battery, and memory stick

4. Putting it into airplane mode and disabling airplane mode about 30 seconds later.

5. Unrooted to original Bell Stock Rom image from a thread and now have normal recovery

6.Data/factory reset

The only thing I do have a possible lead on is that yesterday I created a recovery tar file, from a recovery image I got from cwm website under AT&T, thought it was also for Bell (Model wise) as well, so don't know if that's the case, does that have to do with anything? I'm back to stock recovery and rom and from a thread here: http://xdaforums.com/showthread.php?t=1739426 and downloaded the Bell/Virgin image, and flashed with Odin, I am back to stock, but still did not fix issue. It says Virgin on the top sometimes, and sometimes back to "Emergency calls only" could the recovery flash have changed radio or something? I also did do a restore before I flashed the new recovery and when phone was being normal just before unrooting but that also didn't work. Now I am unrooted and not on custom recovery. But still no service. Most of the time the service is 1 bar, but even when it's on 5 for like 10 seconds, it still doesn't work. Is it me or my carrier? I also noticed that even when the signal shows full strength it tells me "Emergency Calls Only". Thanks for the help.
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] CZ Eddie:
I'd call Virgin and ask if your service was interrupted for any reason.
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] Papaniz:
Yeah I'm going to do that, but I just looked at the IMEI number on the back of the phone, and looked at it in settings, but it did not match the number it had at the back. It just says 0 in the phone settings. Does that have anything to do with it? I wanna know if this is has anything to do with that first before calling.

EDIT: Okay so I did some research and yes that is apparently the problem, so I rerooted to custom recovery, and followed this guide: http://xdaforums.com/showthread.php?t=1801997 my IMEI is back, and matches, and it says "Virgin" now at the top of my lockscreen, but still, I can't send messages or call. Did the deleting of IMEI also delete something else I should restore? Or is it something on their side? I am connected to Virgin Mobile, but the connection is extremely weak, and does not complete any calls or texts. There's also "IMEI SV" under settings and it says "01" is that an issue?

EDIT 2: Nevermind I just had to follow post 3 after fixing IMEI in that thread I linked and it worked! In case you researched and got here. Follow thread I linked up.
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] tutorialhedz:
rise chicken

I'd like to resurrect this thread for a moment. Papaniz's problem is exactly like mine, same carrier & country.. but the link is dead.. any idea what the process was or where another link might be? Thanks Guys
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] BWolf56:
The thread was remove to avoid illegal problem. You'll most likely have to look somewhere else to recover your IMEI if flashing stock firmware doesn't fix it.
[HTC Sensation] johnsmith970:
I'm on the team venom Rom and I checked my data usage, because I got a usage warning, and Android OS is using a lot of data. Last month it was 700+ MB. Anyone know what is going on?
[Asus Transformer TF700] SndChsr:
Hello folks. I've unlocked my Infinity using the Asus unlock tool. Well, all I really wanted was to root it (which I did) but I got the two mixed up and I also unlocked it first. I will never be loading a custom rom therefore I'd rather keep mine locked. This also voids my warranty and I'm afraid I won't be able to receive OTA's.

Is there ANY way to lock the bootloader back up like it was from the factory? If I should keep the pad unlocked, convince me why.

Thanks for any help!
[Asus Transformer TF700] d14b0ll0s:
No, there isn't. Your S/N is already in their database, too. You may use manual firmware updates from their site and they may still respect the warranty (to certain extent?).

There was enough threads on the two for you not to confuse them (as there is about what you can do with being unlocked), so you pretty much rushed into it. Most likely this will not make your life with the Infinity harder, however.
[Asus Transformer TF700] SndChsr:
Dammit. I'm an idiot. Now no OTA for me. Well, I can still return it to where I bought it from. I wish I had paid more attention.
[Galaxy S III Q&A, Help & Troubleshooting] gibbo82:
hi guys, just wondering if anybody has had the same problem before?. I've got not signal/network coverage what so ever! But I'm still getting signal bars! Confused.

It's been like this now for nearly 24hrs@ :(

Please see pictures below.

Gibbo
[Galaxy S III Q&A, Help & Troubleshooting] gibbo82:
Forgot to say I'm in the UK, on 3 network
[Galaxy S III Q&A, Help & Troubleshooting] gibbo82:
Sorted now, had sum settings disabled in network settings. Please lock thread. Thanx
[General Topics] sasuketobi:
How many of you are on kik messenger?
[Verizon Samsung Galaxy S III] opimpao:
I have been looking around the forums and only found one other person that has had this issue and was hoping we could get some help. When I backed up my IMEI using This tread my serial number disappeared and now I get an error whenever I plug my phone into my computer.

When I plug it into my computer this error pops up

Hardware ID Missing

Windows cannot identify the device plugged into the

SAMSUNG Mobile USB Composite Device.

For assistance, contact the hardware manufacturer

If I have to I can revert back to stock and return the phone but I was hoping that this awesome community could help me out!
[Verizon Samsung Galaxy S III] abhinav quietly brilliant:
same here.. zeroes in my phone serial number but not having any other issues
[Verizon Samsung Galaxy S III] Brian Gove:
I get that error when I plug my phone in as MTP. If I switch it to Camera Mode Windows 7 pops up asking me what I want to do, browse/import/etc. I can then browse both my internal and external cards with no problems.

Edit: I don't have zeros for a serial # though
[Verizon Samsung Galaxy S III] shawnten:
i am having the same problem still no fix?
[Verizon Samsung Galaxy S III] annoyingduck:
There are much easier backup methods for the verizon variant over that thread you linked.

That being said, is it possible you applied a restore accidentally? There was a post a ways back where that happened and bad things occurred. I'm looking for the link for you, but yes there was a fix. In work now, may take a while though....
[Verizon Samsung Galaxy S III] shawnten:
i am having the same hardware id missing but my serial number is still there