This is a lengthy post, but please read it. These are copies of my posts on androidforums.
Post 1:
I happily bought my Nexus One 3 weeks ago from someone on craigslist. I checked out the phone, everything worked, and it's been absolutely great. I'm in the Detroit metro area and have T-mobile. I bought it, rooted it, installed cyanogen's 5.0.5.3 ROM and installed the overclocked-undervolted kernel, and it's been heaven. I'm in love with this phone. Then I drove with my dad to Tupelo, MS, on Sunday the 11th and throughout the drive the signal would disappear and come back, repeatedly. I figured this to be because of T-Mobile's terrible coverage. While in Tupelo, I hardly EVER got a signal...even for calling, forget about data. I knew this would be rectified when I got back to Detroit. Today I flew back to Detroit, and finally got 3G again and full signal and I was ecstatic that I could finally USE my phone again! Well that didn't last, now I'm at home (where I normally only get a GPRS signal), and I'm not getting ANY signal, whereas my sister and mother who are sitting next to me, who are on the same family plan with T-Mobile with me, are getting full GPRS signals on their blackberry phones. I've rebooted the phone multiple times, wiped and re-flashed the cyanogen ROM...no luck. I've even put in my sister's SIM card into the Nexus...still no signal. Meanwhile my sister and mother are getting full signal on their phones, even if its just GPRS. I'm bummed PS > No, the phone is NOT in airplane mode.
Post 2:
I did flash the orignal stock rom, and update the radio (tried 3 different radio images)....none of it helped unfortunately. My Nexus One will work fine when I'm in an area of good signal, namely where I get 3G. But when I'm at home, no dice. And the reason this is really frustrating is because everyone else in my house, on the SAME carrier, with the SAME plan, is getting a full signal. This really sucks because not only is the phone useless as a phone, but the phone runs hot (31 degrees C at idle, instead of 24 C at idle, which it what it always was before), because it's always looking for a signal (and I know this because Call Standby, which used to be 3% of battery use, is now the highest battery drain). And until I left for the trip, this was not a problem at all. So my only conclusion is that while in Tupelo, MS, the antenna/radio fried a bit, constantly looking for a signal for 4 days straight, and so now it can only pick up signals if they're very strong. Either way, I'm gonna have to sell it to someone who wants it for repair parts, and go back to my old blackberry pearl 8100
Post3:
Sent the phone in to HTC.
This is what they told me. I could go two routes: Replacement or Repair. Naturally I'd just want them to send me another certified working phone (refurbished, they don't send new ones). However, with this option, since I wasn't sure if I was under warranty or not (having unlocked the bootloader and rooted the phone, and the customer service guy said they could only determine that once the phone was with them), if they determine that you are NOT under warranty, you will get a replacement, but the cost of any repairs that are needed to the unit you send in, you WILL pay for them, no matter what. If they determined that I am still under warranty and that they can help me free of charge, then obviously this would be the best option. But not knowing if I'd be charged, and how much I'd be charged, I took the repair option.
With the repair option, they give you the option whether you want to authorize the charges once they know how much it will cost (if they can't do it for free). Then you can decide if it's worth the money they're saying, or you can tell them to just send it back, in which case they'll just charge you 28$ for the diagnosis and shipping cost to ship it back. I took this option worried about them telling me that I'd have to pay 300$ or something crazy for the repair if I took the replacement option.
I sent it in on Friday the 16th, and I got a mail from HTC on Monday 10 AM the 19th, telling me they had received the phone. Then at 5 PM I get an email from them saying it's been shipped back. That's it, no other info. I thought, how can they fix it that quick? Or did they mistakenly not even look at it and sent it back with a batch of repaired phones? Or did they just send me a replacement?
I got the phone yesterday the 20th at noon, and opened the package, and it was in fact my phone (it still had the screen protector I'd put on it, albeit they'd completely ruined it, because it had moved and now had all these large air bubbles and dust in it).
I powered it on and the bootloader was locked again, and completely returned to stock. I was at my house at this time, where I've been getting the signal problems (while everyone else at my house, with the same carrier and same plan have been getting full GPRS signal). I pop in my SIM card and YES! It was working, and working well. Made a few calls, walked all around the house, and the calls were clear and strong.
Now at this point, it was a bittersweet feeling, because while my phone was working, I was afraid to root it again. I guess I felt that somehow rooting my phone and intalling Cyanogen's mod 5.0.5.3 must have done it (though I had that ROM on for a while before my trip, when it got messed up). But then I coudln't handle the slower speed, the lack of quicker pulse trackball notifications, wireless tether, titanium backup...and so on. So I rooted my phone, installed cyanogen's mod, downloaded all the apps I had.
Except ONE thing. The only thing I can remember doing before my phone's signal started getting weak was installing an overclocked+undervolted kernel to the phone. I know they say that when your phone is in a weak area, it requires more power to work, so maybe undervolting it is what was doing it, but this doesn't make sense, as I reflashed the cyanogen mod without the kernel, and the stock rom and neither helped. Wouldn't they overwrite the kernel with the kernel's in the ROMs? Either way, that was the last thing I did to my phone before it started messing up, so while I put on every app (including setcpu) back on my phone, I didn't put the kernel on it.
So far so good, it's been a whole day, and it's worked fine at my house. All I can say is I'm enjoying my phone again. Thanks to all of you, and I hope this thread helps out someone else in a similar predicament.
Now that my phone is working fine, and the only thing I have not put back on my phone is the undervolted+overclocked kernel, I'm wondering if that's what ruined my reception at home, which is a weak signal area.
The thing that confuses me is that I thought when you flash a ROM, it over-writes the kernel with its own, but even though I flashed the stock and cyan's ROMs after full wipes, it didn't fix the problem, so I'm assuming that kernels don't get over written?
Since you guys are the experts, what do you think happened to my phone?
I am now afraid to even TRY to do anything to the phone. I really wanna try out Modaco's desire rom to try out sense UI, but I feel like I'll just risk my phone's reception again.
No, kernels do get overwritten. But, in some cases, caches can causes issues with the system interaction with the radio. Undervolting WILL screw with your radio.
bobtentpeg said:
No, kernels do get overwritten. But, in some cases, caches can causes issues with the system interaction with the radio. Undervolting WILL screw with your radio.
Click to expand...
Click to collapse
Why is that?
bobtentpeg said:
No, kernels do get overwritten. But, in some cases, caches can causes issues with the system interaction with the radio. Undervolting WILL screw with your radio.
Click to expand...
Click to collapse
What cache are you talking about?
Unfortunately because of this experience I don't feel like messing with my phone again :-(
i would also like to hear why undervolting the processor would affect radio signal, as i did not think that the power supplied to the transceiver would be any different.
Running many devices at voltages outside of optimal parameters shortens their lives even if they function normally for a while. Under volted motors can burn up, which is why power brown outs can be especially dangerous. Could low voltage impact a radio? Yep - I learned that lesson in playing with early solid state ham radios. The radio is especially susceptible if the radio voltage is already automatically adjusted to conditions.
I don't what exactly is under volted with these UV kernels. I assume the CPU is under volted, but what else? Who has physically tested voltages at various places to confirm expected results?
One thing is for sure - if nothing other than the CPU voltage is adjusted with the UV kernel, then it's highly unlikely under volting caused your problem.
But if the voltage adjusted is more systemic, then the UV kernel could absolutely have an impact on the life of any component in the phone.
Just to add to what's already been said... I have yet to see solid evidence that undervolting really makes a substantial impact on battery life. If you really want to root, don't overclock the processor or undervolt it. The extra 113mHz you're getting isn't worth it, IMO. The phone's already fast stock...so with the .32 kernel it's probably more than adequate.
uansari1 said:
Just to add to what's already been said... I have yet to see solid evidence that undervolting really makes a substantial impact on battery life. If you really want to root, don't overclock the processor or undervolt it. The extra 113mHz you're getting isn't worth it, IMO. The phone's already fast stock...so with the .32 kernel it's probably more than adequate.
Click to expand...
Click to collapse
Right.
Further, if you expect to improve battery life by lowering CPU voltage, you also need to lower the frequency of the clock. Ohms law applies - it takes X amount of watts to do any task with electricity, that amount varies from device to device. But the wattage required to do a specific job with a specific device remains constant. There are two variables that determine power (wattage) - volts and amps. Decrease voltage, and the device will draw more current (amperage) to do the task.
In the case of a CPU, in you overclock (expecting it to perform at a higher level) then you need to supply more power. If you raise the clock speed and lower the voltage, then the current MUST increase accordingly. I don't understand how lowering voltage without lowering the workload (clockspeed) could possibly improve battery life, and I don't see any valid testing to prove that whatever is being done really works.
All that said, I still have no idea how available voltage mods are impacting the mean time between failure rates of handsets they are installed on. Benefits are anecdotal IMO, until I see some valid test data and a better explanation of what's going on.
uansari1 said:
Just to add to what's already been said... I have yet to see solid evidence that undervolting really makes a substantial impact on battery life. If you really want to root, don't overclock the processor or undervolt it. The extra 113mHz you're getting isn't worth it, IMO. The phone's already fast stock...so with the .32 kernel it's probably more than adequate.
Click to expand...
Click to collapse
Is there a way to check the kernel version in the phone?
Also if I want to try out a custom ROM, how do I make sure that I keep the .32 kernel (which I'm assuming you mentioned because it is the default kernel) ?
ksc6000 said:
Is there a way to check the kernel version in the phone?
Also if I want to try out a custom ROM, how do I make sure that I keep the .32 kernel (which I'm assuming you mentioned because it is the default kernel) ?
Click to expand...
Click to collapse
settings > about phone
and, i'm running intersectraven's avs kernel. it does seem to help battery life. it adjusts voltage based on cpu demand
attn1 said:
Right.
Further, if you expect to improve battery life by lowering CPU voltage, you also need to lower the frequency of the clock. Ohms law applies - it takes X amount of watts to do any task with electricity, that amount varies from device to device. But the wattage required to do a specific job with a specific device remains constant. There are two variables that determine power (wattage) - volts and amps. Decrease voltage, and the device will draw more current (amperage) to do the task.
In the case of a CPU, in you overclock (expecting it to perform at a higher level) then you need to supply more power. If you raise the clock speed and lower the voltage, then the current MUST increase accordingly. I don't understand how lowering voltage without lowering the workload (clockspeed) could possibly improve battery life, and I don't see any valid testing to prove that whatever is being done really works.
All that said, I still have no idea how available voltage mods are impacting the mean time between failure rates of handsets they are installed on. Benefits are anecdotal IMO, until I see some valid test data and a better explanation of what's going on.
Click to expand...
Click to collapse
Sorry I saw this and felt its nessisary to comment on it.
When you overclock a processor a general rule is that you increase the voltage to the processor to provide stability. (Since more clock cycles typically require more power. Not every chip is manufactured the same, it may be the same model, but they are fabricated differently. One processor might be stable with less voltage compared to another one from a different batch of processors.)
With the N1, Google ensured stability by increasing the voltage sent to the processor. As time has shown, the roof Google put on the device for stability could be lowered and still have a stable phone. (Hence 1000mv to 800mv stable.) Underclocking or undervolting WILL NOT DAMAGE a processor in no way shape or form. It doesn't happen. ONLY when you overvolt a processor do you risk damaging it. (More voltage = more heat) (I'm not saying you can't brick phones from doing it, just simply saying you are not damaging the hardware itself.)
Typically every device inside a phone has its own regulated voltage, if the radio voltage hasn't been touched, undervolting your processor shouldn't affect the stability of the radio.
timothydonohue said:
settings >, i'm running intersectraven's avs kernel. it does seem to help battery life. it adjusts voltage based on cpu demand
Click to expand...
Click to collapse
"seem to" is sort of anecdotal. Battery life is a hard thing to measure on something like a mobile phone, because the test parameters change so much from day to day in normal operation.
In order to test battery usage from kernel to kernel properly, the phone needs to be fully charged and then run a looping task that logs with a timestamp. All other system tasks and features running as this task runs need to be documented, and the phone cannot be used otherwise. When the battery dies, it should leave a log that notes the time the task started and the time the task ended, provided the phone didn't crash mid-write.
If the clock frequency is determined by load, then the loop needs to be adjusted so that the CPU can idle longer between loop cycles, this way a matrix can be built measuring battery performance under different loads. The test should be rerun with several different loop intervals, and each result documented carefully.
Then change out the kernel and repeat each test exactly the same way. Proper testing is meticulous work, and until it's done, we have no idea what, if any impact an under volted kernel has on battery life.
This may not be the best way to test, and it surely isn't the only way, but something with more control than day to day phone use is needed to prove that battery life is actually improved.
I have yet to see any kind of test designed, and I have no clue how it could work, unless undervolting results in under clocking. Same work has the same energy requirement. If a lower voltage means a lower CPU clock, then yes, it can work, like speed stepping does on a PC. Under heavy use, an overclocked CPU is going to use more energy, regardless of how voltage is applied while it is overclocked. Since the screen uses a pretty hefty percentage of power when in use and with all the data pushes going on with these devices, I don't see overclocking helping much unless the device is throttled down and sleeping far more than it is used.
Ohms law.
archangelugp said:
Sorry I saw this and felt its nessisary to comment on it.
When you overclock a processor a general rule is that you increase the voltage to the processor to provide stability. (Since more clock cycles typically require more power. Not every chip is manufactured the same, it may be the same model, but they are fabricated differently. One processor might be stable with less voltage compared to another one from a different batch of processors.)
With the N1, Google ensured stability by increasing the voltage sent to the processor. As time has shown, the roof Google put on the device for stability could be lowered and still have a stable phone. (Hence 1000mv to 800mv stable.) Underclocking or undervolting WILL NOT DAMAGE a processor in no way shape or form. It doesn't happen. ONLY when you overvolt a processor do you risk damaging it. (More voltage = more heat) (I'm not saying you can't brick phones from doing it, just simply saying you are not damaging the hardware itself.)
Typically every device inside a phone has its own regulated voltage, if the radio voltage hasn't been touched, undervolting your processor shouldn't affect the stability of the radio.
Click to expand...
Click to collapse
As voltage decreases at a given CPU frequency, amperage must increase. An extension cord used properly should be cool. Overloaded, voltage will drop and current is increased to meet the power requirement of the load, increasing heat. So reducing heat is not as simple as lowering voltage - the load must be lowered.
Your point about each device having it's own voltage regulator is well taken, and while they will protect individual devices (like radios) from damage from voltage variances, there is still no proof that an overclocked/undervolted CPU improves battery life with moderate use, however power is applied. To lower power requirements, the workload must be lowered accordingly.
You guys seem pretty knowledgeable about all this. What do you think happened to my phone that I stopped getting reception at home but as soon as I got it back from HTC it was fine? All they did was un root the phone and re lock the boot loader. What did they do that I didn't do by re flashing the ROMs and trying 3 different radios? They didn't seem to have messed with any hardware.
ksc6000 said:
You guys seem pretty knowledgeable about all this. What do you think happened to my phone that I stopped getting reception at home but as soon as I got it back from HTC it was fine? All they did was un root the phone and re lock the boot loader. What did they do that I didn't do by re flashing the ROMs and trying 3 different radios? They didn't seem to have messed with any hardware.
Click to expand...
Click to collapse
It's very unlikely that they simply unrooted and relocked the bootloader. Is the serial number of the system board the same? I suspect that HTC determined that the radio was defective and the system board was replaced, explaining why your screen protector was dislodged. You weren't charged for a new system board because they attributed the failure to hardware and gave you a pass. With a new system board the phone was once again boot loader locked.
It was probably a bad radio module completely unrelated to anything you did. It happens, and that's my guess at this point.
i'm also running intersectRaven's undervolted kernel and have not had any issues with signal on my Nexus 1 / at&t version. it's been a solid 4-bars with "H" speeds. with the T-Mobile version I would consistently experience 3G signal drops and reconnects, but did not think it was due to the kernel. battery life was good but usually suffered due to signal issues. fyi, i created a Nandroid of my T-Mobile version and restored to my at&t version. the only difference is the radio. and i can say through my testing that my battery is lasting longer; probably due to better signal strength. i really appreciate the feedback and comments from those more knowledgeable than me on the kernels. i'll continue to monitor my device going forward.
attn1 said:
Ohms law applies - it takes X amount of watts to do any task with electricity
Click to expand...
Click to collapse
Please state your source, as that isn't ohms law at all. "Ohm's law states that the current through a conductor between two points is directly proportional to the potential difference or voltage across the two points, and inversely proportional to the resistance between them."
Or, in another form:
v=ir
If you drop the voltage, the right side of the equation must also go down. We can assume that resistance stays approximately the same (this isn't true, but it is close enough). Thus, current (i) must also go down.
The power equation is p=iv. Rmember, both current AND voltage go down. Thus, power must go down as well. Substituting for i, we get p = v^2 / r. So power is directly proportional to the square of voltage. Decreasing the voltage from 1275 mV to 800 mV actually reduces power consumed by over 60%. Wow.
Of course, you can't actually reduce voltage by that much and keep the same clock speed. However, my point was that reducing voltage reduces power, which remains true.
attn1 said:
But the wattage required to do a specific job with a specific device remains constant.
Click to expand...
Click to collapse
That's wrong. The reason is not all power goes into doing useful things like switching transistors, a lot of it is lost for charging/discharging the capacitances of on-chip wiring, I/O busses, and parasitic capacitances as any transistor has them (dynamic power, used while switching). The dissipation loss is P = C*V^2*f, i.e., it is linear in the frequency and quadratic in the voltage. See http://en.wikipedia.org/wiki/CMOS#Power:_switching_and_leakage for details. This is the main reason why undervolting saves power.
This article is a nice summary: http://en.wikipedia.org/wiki/Dynamic_voltage_scaling
Related
748/245
Temp < 50C 245/245 100
Screen Off 245/245 90
Charging/Full 719/245 80
Battery <40% 604/245 70
All ondemand
Temp > 42.1 528/245
Screen Off 528/160
Charging/Full 768/768
Battery <100% 768/245
that's listed by priority
Hungry Man said:
Temp > 42.1 528/245
Screen Off 528/160
Charging/Full 768/768
Battery
Click to expand...
Click to collapse
Screen Off: 245-480
**Stock is 245-245. 160 as a minimum seems to produce a LOT of wait time from when the call is coming in to when the phone lights up. More than 245 seems to whack the battery.
Keep in mind, when you wake up your phone, this Screen Off SetCPU Profile is active for at least a SECOND or two. The problem is that if you have your maximum at 245, you experience BAD lag trying to pull the lock bar down. At 245-480, the maximum is high enough that a) the lock bar pulls down as smoothly as a stock Eris, and b) even if SetCPU takes a couple of seconds to change the profile, at least you're at 480mhz for the first scrolling of the screen left/right (so you don't embarass yourself in front of iphone users). Anything higher than 480mhz is a different voltage. Almost the whole time your phone is 'Screen Off', it will be operating at 245 anyway. So 480 is a good setup for it to jump up when a call comes in (to play the ringtone and show the picture a little faster, and for the lock screen bar to pull down smoothly, and the first second of SenseUI to be smooth enough, until your phone changes the profile to your <100% profile.
Battery <100% 245-806
** Zanfur's take on how this processor clocks up/down its speeds will lend itself to a general wisdom that 768mhz isn't really slower than 806mhz, and that in instances of high variability of clock speed (aka you have some Power Save bias in SetCPU keeping it lower/higher at random, or you're doing very intermittent tasks), the processor rests at 768mhz more quickly, and wastes less time/'effort' changing speeds. Changing to 806 is another 'step' altogether, where 245 to 528 is one 'step', and that to 768 is another 'step'. Going to 806 is absolutely another step yet after that (which means your phone responds a LITTLE slower because it has one more step to 'throttle' up to). BUT, if you're doing a dedicated task, such as running a Linpack benchmark (which is a terrible benchmark anyway) your phone will move faster at 806, or if you're playing a game, or playing a video... generally the processor will stick at one speed (and not have to 'step' up or down), so 806 is faster. I clock friends' phones at 768 to avoid problems, keep it clean, etc etc. Some people put the minimum here at 160mhz, but I feel that this is too low (and another 'step', just like 806 is over 768, 160 is another step down from 245).
Charing (any) 480-806
** I keep the minimum here HIGHER than when the phone is on battery, because I'm less concerned about how much energy it's consuming, and having a minimum of 480 makes the phone very snappy no matter what, from the second you touch it
Overheating > 48C 122-528
** Clock speed here matters a LOT less than just getting your phone out of the heat. This phone doesn't overheat because it's overclocked, it overheats because you run it at an overclocked speed for a long time. MOST overheating instances are from wireless tethering and from broken charging systems (that keep trying to charge the battery and generate a lot of heat). The 'Failsafe' profile here provides a 'notification' option which I HIGHLY recommend.
My ex-gf's Eris actually CAUGHT FIRE, as in it looked like it was a zippo, right above the volume buttons. It used to overheat EVERY NIGHT that it was on the charger, excessively, so hot that you couldn't touch it. For a month or two it did this, actually, and caused no real damage to the phone. Since the night of the Flame (you can actually see the melted plastic and even on the outer case - she has a blue snap shell case on it that is melted as well), the phone has NOT overheated even one time on the charger. (Sorry for the story, it was a waste of time).
The point is that, the first time it happened, her phone System sound was on Silent, and she DIDN'T hear the notification that her phone was overheating. Apparently it doesn't matter (or she's very lucky her phone isn't damaged in terms of its operation!) how much it overheats for some people, but I like to have it warn me it's getting close to 50C. The notification's the important part there (so u can cool your eris), not the clock speed.
@pkopalek I like your settings you posted with a full description of each. I changed my settings to yours and give it a day or so and will report a status update as to performance quality
I've never lagged at 160mhz =p but that could just be my phones/ roms.
Hungry Man said:
I've never lagged at 160mhz =p but that could just be my phones/ roms.
Click to expand...
Click to collapse
my audio skips and it won't wake up when in a call at 160mhz. I keep mine at 245mhz minimum to keep phone working smoothly.
What does the different prioritys mean? Is that like what one its.focused on more?
Sent from my FroShedYo.V5 using XDA App
How do you guys clock your CPU so high? Whenever I try anything over 729 bad stuff happens. If I put it on 748 it lags and if i try 768 it freezes up. You guys are all using the droid eris right? What ROMs and kernels are you running? I'm on Kaosfroyo
sgbenton said:
How do you guys clock your CPU so high? Whenever I try anything over 729 bad stuff happens. If I put it on 748 it lags and if i try 768 it freezes up. You guys are all using the droid eris right? What ROMs and kernels are you running? I'm on Kaosfroyo
Click to expand...
Click to collapse
When a processor is made at the factory, it will always have flaws in it. The chip is tested to see what frequency it is stable at. So that is the speed that is stamped on the chip and the frequency that it is set at to operate for the consumer and not have any problems. When you overclock a processor, you are bypassing the frequency that the chip as been deemed to be stable at. After that, there is no set speed that your processor can handle, because each one is different according to the flaws it might have.
So in short (what I'm trying to say), the processor in your phone just can't handle those without causing problems. That's why when you overclock it, it's kind of a trial-and-error process to see what speed you can get out of it, but be careful, because too high can cause permanent damage.
Using Interactive governor
Main: 787/710
Temp > 42.1 C: 480/245 Priority: 100
Screen Off: 480/245 Priority: 95
Charging/Full: 480/245 Priority: 90
Please read this first, I'm pretty sure the problem is linked to this accident:
http://forum.xda-developers.com/showthread.php?t=1056606
For a short time my phone is lacking performance when it isn't connected to something (slow menu animations, snatchy performance in games etc.). Quadrant Benchmark proofs that circumstance too. Without connection my device achieves 'bout 500 points, when it is connected it gets ca. 1000 points. With "CPU Master Free" I've clocked the SGS once to 1Ghz and once to 1,2GHz. In both cases the performance gets better, but still is not as good as when the phone would be charged. Only then it really runs smooth.
I hardly expect you guys can give me another solution than sending the SGS to the repair service, 'coz imho the GPU has suffered certain damage...
nidschki said:
Please read this first, I'm pretty sure the problem is linked to this accident:
http://forum.xda-developers.com/showthread.php?t=1056606
For a short time my phone is lacking performance when it isn't connected to something (slow menu animations, snatchy performance in games etc.). Quadrant Benchmark proofs that circumstance too. Without connection my device achieves 'bout 500 points, when it is connected it gets ca. 1000 points. With "CPU Master Free" I've clocked the SGS once to 1Ghz and once to 1,2GHz. In both cases the performance gets better, but still is not as good as when the phone would be charged. Only then it really runs smooth.
I hardly expect you guys can give me another solution than sending the SGS to the repair service, 'coz imho the GPU has suffered certain damage...
Click to expand...
Click to collapse
hmm, no idea about any of this so I might as well give you a bump
If I remember there was programs like SetCpu that would set different behavior on charge and no charge. But was a loong time ago. Since I have no idea what rom or kernel you use. Are you sure there is not program/setting/rom setting active that underclocks your SGS whilst not on charge?
Sorry, forgot to mention: I'm using Goatrip's ROM 1.9 with CF Kernel.
I just have a few apps installed, none of them would under- or overclock the system. And as I sad, i don't know how but for me it seems that the problem is linked to the accident. At least it's somehow related to the battery.
Welcome to Myrt Torture Tester.
As always, this app is BETA, expect bugs. Tested on Stock GB/HP Extreme & guestekrnL, CM7/Etana, CM9/HP ICS & Harsh.
Will only work on OC/UV-kernels.
It's primarily intended as a tester to find your stable frequencies and voltages, but can also be used as a battery-life tester and a rough benchmark.
This app comes with no more support than the 2nd post. If you don't know how to use it after reading that you don't need it.
Using this app, you will be capable of causing actual damage to your device. I take no responsibility for any consequences.
This app shall under NO CIRCUMSTANCES be included in any ROM, or uploaded any other place than this post.
Changelog
0.5.6 - Fixes crash when system is unresponsive for long periods.
0.5.5 - Keeps reading the current cpu-frequency throughout the test. (Some beta kernels unexpectedly change frequencies during the test, this allows you to see it.)
0.5.4 - CM7-compatability-fix.
0.5.3 - Fixes frequency not being set on guestekrnL.
0.5.2 - Fixed links on about page.
0.5.1 - Plays nice on non-oc kernels.
0.5.0 - First BETA-release
HOW TO USE:
In its simplest form, the app is a benchmark. You start a CPU-test at a specific frequency for a specific time-period and get the average Mflops-result. If you are going to compare different kernels, it will give you a normalized to 1Ghz result as well. Different kernels usually have different frequency-tables, so test them at the closest steps you can find, then compare the normalized result.
The more useful aspect of it is to test if a specific frequency is stable at a specific voltage. The app only allows to test the frequencies in the voltage table - because if it is stable at those frequencies it will be stable at all other frequencies which fall within those voltage-steps. If you have undervolted too much, the phone will usually reboot pretty quickly. If you have undervolted "on-the-edge", the phone will likely freeze. If you have undervolted so that it is basically stable, but sometimes fails, you'll either get a crash to the desktop or MTT will inform you of a calculation error. If you are testing for stability you need to test for at least 60 minutes to have any confidence in the result, I've had several tests fail after 45-50 minutes.
It can also be used to see what impact, if any, undervolting has on the processors' power-consumption. After you have made sure a frequency/voltage-pair is stable, you can run a battery-test and compare it to an identical test at stock voltage. This will simply run from a full(ish) battery to a certain battery percentage, and give you how long it was able to run. Since the battery-percentage is pretty loosely coupled to the actual battery-charge, it will also give figures for consumption per minute or second. This kind of test should also be run over a long a period as possible to get accurate results. Measuring from 100% to 90% will only give you an indication, prone to error. You can not compare a test between, say 100->50 and 100->20, because the discharge rate varies with the charge-level.
For most accurate testing and benchmarking: enable flightmode, unplug the device, freeze any apps which may run in the background, uninstall everything you don't need, wait 3 minutes after booting before testing, do not touch the screen or move the device while a test is running. Even then there are Android quirks which will cause some variation in the results. Therefore the same test should be repeated as many times as you can afford.
The major enemy of stability, assuming you have enough voltage, is heat. Make sure to test the device under the same conditions as it will be used. If you're going to overclock on a hot summer's day, test it on a hot summer's day. MTT dims the screen to minimize the impact it has on the battery and heat-generation, be aware that your device will be hotter when the screen is at normal brightness.
Stability tests should also be performed at different battery-levels. If your device is stable when the battery is fully charged, it does not automatically mean it will be stable when it is almost discharged.
MTT logs all succesfull tests (max 200 lines.) If you enable "Store log on sdcard" in preferences the log will be saved to /sdcard/MTT_Log.txt.
Known issues:
o Sometimes the device will give you half the score you should get. I do not know if this is a kernel or android-bug, but it seems that both test threads get scheduled to run on the same core, and the second core goes unused, even when it is active. Exiting the app and starting it again does not help usually, but killing it sometimes does. Rebooting is always an option.
o Not a "known issue", but this app lets you under- and overvolt in 5mV steps. Different kernels may handle this differently, either not undervolting at all, or adjusting it to the nearest 25mV step. It has worked on the kernels I have tried, but there are too many kernels out there to be sure.
TrymHansen said:
HOW TO USE:
In its simplest form, the app is a benchmark. You start a CPU-test at a specific frequency for a specific time-period and get the average Mflops-result. If you are going to compare different kernels, it will give you a normalized to 1Ghz result as well. Different kernels usually have different frequency-tables, so test them at the closest steps you can find, then compare the normalized result.
The more useful aspect of it is to test if a specific frequency is stable at a specific voltage. The app only allows to test the frequencies in the voltage table - because if it is stable at those frequencies it will be stable at all other frequencies which fall within those voltage-steps. If you have undervolted too much, the phone will usually reboot pretty quickly. If you have undervolted "on-the-edge", the phone will likely freeze. If you have undervolted so that it is basically stable, but sometimes fails, you'll either get a crash to the desktop or MTT will inform you of a calculation error. If you are testing for stability you need to test for at least 60 minutes to have any confidence in the result, I've had several tests fail after 45-50 minutes.
It can also be used to see what impact, if any, undervolting has on the processors' power-consumption. After you have made sure a frequency/voltage-pair is stable, you can run a battery-test. This will simply run from a full(ish) battery to a certain battery percentage, and give you how long it was able to run. Since the battery-percentage is pretty loosely coupled to the actual battery-charge, it will also give figures for consumption per minute or second. This kind of test should also be run over a long a period as possible to get accurate results. Measuring from 100% to 90% will only give you an indication, prone to error. You can not compare a test between, say 100->50 and 100->20, because the discharge rate varies with the charge-level.
For most accurate testing and benchmarking: enable flightmode, freeze any apps which may run in the background, uninstall everything you don't need. Even then there are Android quirks which will cause some variation in the results. Therefore the same test should be repeated as many times as you can afford.
The major enemy of stability, assuming you have enough voltage, is heat. Make sure to test the device under the same conditions as it will be used. If you're going to overclock on a hot summer's day, test it on a hot summer's day. MTT dims the screen to minimize the impact it has on the battery and heat-generation, be aware that your device will be hotter when the screen is at normal brightness.
Stability tests should also be performed at different battery-levels. If your device is stable when the battery is fully charged, it does not automatically mean it will be stable when it is almost discharged.
MTT logs all succesfull tests. If you enable "Store log on sdcard" in preferences the log will be saved to /sdcard/MTT_Log.txt.
Click to expand...
Click to collapse
Really interesting! Big thanks
Sent by LG Optimus 2x
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc results in that new max freq being used all the time in the program.
kfallz said:
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc also results in that new max freq being used all the time in the program.
Click to expand...
Click to collapse
Ok, thanks for the feedback. Which version of guestekrnL? I'm mainly using that myself, works here on 1.7.
EDIT: Ok, I've found the reason. I had disabled the 00cpufreqenabler script (to simulate other kernels), but it didn't work after I enabled it. Will release a fix as soon as I can override the permission properly.
kfallz said:
Doesn't seem to work for me, always goes to my max set freq of 1.1ghz, no matter if i set it higher or lower in the program. Same mflops result too. Changing the max freq in guesteoc results in that new max freq being used all the time in the program.
Click to expand...
Click to collapse
App updated to 0.5.3 - fixes the issue where frequency is not set on guestekrnL.
TrymHansen said:
App updated to 0.5.3 - fixes the issue where frequency is not set on guestekrnL.
Click to expand...
Click to collapse
Giving the new version a try, and not that it matters now but I'm using 1.7.0t2
Yea working fine now
Updated to 0.5.4 - Now the sliders behave properly on CM7.
Myrt, do you think that we have more than one different hardware inside our phones? Because the results are way to different from one ppl to another, for example, Temasek can't OC even to 1.1GHz, and Vadonka puts at 1.4GHz without the burn, with the tests, I get to 70ºC in 2min with 1.1GHz, but the strange thing, is that the phone doesn't lags or anything to show that it haves an high-temp. Did you have some screen of the test in your own phone? I have exchanged my first phone because it always get too hot for me, my second gets hot always when I try to play any game.
chaozbr said:
Myrt, do you think that we have more than one different hardware inside our phones? Because the results are way to different from one ppl to another, for example, Temasek can't OC even to 1.1GHz, and Vadonka puts at 1.4GHz without the burn
Click to expand...
Click to collapse
No, we have pretty much the same hardware, specification-wise. It is very common to have different tolerances for speeds and voltages. I'm pretty sure that the moment Vadonka tries my app at 1.4Ghz, he too will get a hot CPU.
, with the tests, I get to 70ºC in 2min with 1.1GHz, but the strange thing, is that the phone doesn't lags or anything to show that it haves an high-temp.
Did you have some screen of the test in your own phone? I have exchanged my first phone because it always get too hot for me, my second gets hot always when I try to play any game.
Click to expand...
Click to collapse
I didn't take a screenshot, if that is what you ask, I have the app abort the test at 72C, and the temp falls quickly back to normal. I don't even have vadonkas kernel installed anymore, I'm a stock man, installed CM7 just to make the app compatible.
However, I guess we can encourage people to post their temps and frequencies here, in this thread. If anyone manages to run 1.4Ghz for more than 5 minutes and not reach 70C I'll be impressed. (I do all my temp-testing when plugged in though, probably easier when unplugged.)
TrymHansen said:
No, we have pretty much the same hardware, specification-wise. It is very common to have different tolerances for speeds and voltages. I'm pretty sure that the moment Vadonka tries my app at 1.4Ghz, he too will get a hot CPU.
I didn't take a screenshot, if that is what you ask, I have the app abort the test at 72C, and the temp falls quickly back to normal. I don't even have vadonkas kernel installed anymore, I'm a stock man, installed CM7 just to make the app compatible.
I had these temps in Spica HP kernel, so stock rom, CM7 with Vadonka, I saw an 84ºC (leave my brother playing in the phone, and he said to me that the phone was hot haha)
Click to expand...
Click to collapse
TrymHansen said:
However, I guess we can encourage people to post their temps and frequencies here, in this thread. If anyone manages to run 1.4Ghz for more than 5 minutes and not reach 70C I'll be impressed. (I do all my temp-testing when plugged in though, probably easier when unplugged.)
Click to expand...
Click to collapse
If we can't run 1.4GHz for me than 5min without reaching 70ºC, and 70ºC is the maximum temp, we can't play or let the phone in the frequency for daily use?
chaozbr said:
If we can't run 1.4GHz for me than 5min without reaching 70ºC, and 70ºC is the maximum temp, we can't play or let the phone in the frequency for daily use?
Click to expand...
Click to collapse
Well, no, I'm not saying that, there are too many unknowns.
1) We don't know if the reported temp is correct.
2) We dont' really know the max temp for tegra2. (The 70C figure is not from an official source.)
3) This app is meant to test stability, so temps will get as hot as possible. A game will most likely not stress the CPUs quite as much.
But, all that taken into consideration, 1.4Ghz is probably too high for sustained operation. It will probably be fine for normal use, where the CPUs get to rest once in a while, but not for prolonged CPU-heavy tasks (which this app demonstrates.) That being said, this app is designed to produce as much heat as possible to test stability.
It took me 41sec till the CPU reached 70°C from 40°C on 1408MHz using latest beta 3.0.y etana.
Tapatalk 2-vel küldve az én Optimus 2X-ről
Thanks for this, this app looks great!
I usually don't UV as it introduces some instability to my device even at low -UV values which isn't worth the rather small gain in battery life - but it's still good to know that this app existis if I'll change my mind someday
tonyp said:
Thanks for this, this app looks great!
I usually don't UV as it introduces some instability to my device even at low -UV values which isn't worth the rather small gain in battery life - but it's still good to know that this app existis if I'll change my mind someday
Click to expand...
Click to collapse
Yeah, I don't usually undervolt either, I carry spare batteries, and the fear of unstability was always lurking when I did. (I did make an undervolt app afterall, had to test it.)
So with this app my hope is that many myths will be dispelled - using this people should be able to find out what they need.
(A few weeks ago I had forgotten the batteries in a bag in a hotellroom, far away. I really, really, really needed 20 extra minutes of battery-life then. So now I will probably undervolt to voltages I know are safe, just in case something similar should happen. Sometimes 5 minutes make all the difference in the world.)
I cannot set any other V (no UV or OV) using Temasek 99 with latest Vadonka Beta 11.05. Kernel. The program always crash after the 2sec warmup.
Gesendet von meinem Optimus 2X mit Tapatalk 2
kennbo82 said:
I cannot set any other V (no UV or OV) using Temasek 99 with latest Vadonka Beta 11.05. Kernel. The program always crash after the 2sec warmup.
Gesendet von meinem Optimus 2X mit Tapatalk 2
Click to expand...
Click to collapse
Ok, I need some more info I think. First of all, is the app the latest version? If yes, do you get a superuser message the first time you start the app after a reboot? Which values do the bottom sliders show right after starting the app for the first time?
Tried it myself today on temasek 100 with both 3.0.31 OC and the latest beta (OC-only of course), worked on both for me. One installation however failed, and I had to repair the system-partition before the app would work again. (Superuser pretended to give access, but /system wasn't really writable, so it failed.) Check which apps are listed in superuser, if you see the same app listed a lot of times, that's your problem.
TrymHansen said:
Ok, I need some more info I think. First of all, is the app the latest version? If yes, do you get a superuser message the first time you start the app after a reboot? Which values do the bottom sliders show right after starting the app for the first time?
Tried it myself today on temasek 100 with both 3.0.31 OC and the latest beta (OC-only of course), worked on both for me. One installation however failed, and I had to repair the system-partition before the app would work again. (Superuser pretended to give access, but /system wasn't really writable, so it failed.) Check which apps are listed in superuser, if you see the same app listed a lot of times, that's your problem.
Click to expand...
Click to collapse
Sooorry I'm too stupid, tried the 216 Mhz only which is too slow for the total phone use and test. Program works fine!
Again sorry and thanks for the tool
kennbo82 said:
Sooorry I'm too stupid, tried the 216 Mhz only which is too slow for the total phone use and test. Program works fine!
Again sorry and thanks for the tool
Click to expand...
Click to collapse
Ok, good to know, thanks. I will have to look into it anyway, it shouldn't crash even at 216Mhz, but I'll take that as low-priority, in other words tomorrow ;-)
I have noticed the Xiaomi Mix has some persistent software thermal throttling after a short period of time.
I ran the same test on a OnePlus 3T and noticed this throttling issue is not present.
It's possible the temps to start throttling are too low on the Mix.
Is there any way to modify or increase these throttle limits?
I know this has been done before but I cannot load the Thermal conf file in /system/ etc / thermal-engine.conf
Can we replace the file with something else ?
The OnePlus forum members released several versions of the file with different throttling temps. Can we use these files or make our own.
https://forums.oneplus.net/threads/oneplus2-how-to-fix-thermal-throttling.417108/
Did you ever get any further with this? My phone idles at ~35C. I read a review that said throttling begins at ~40C so I get throttled when I do virtually anything.
I've only had this thing 2 days and the performance has been worse than my old Nexus 6 because the cores keep getting capped very low. I was copying some backed up files over WiFi from my PC. It was lots of small files so it was running for 20 mins or so. When I was trying to do other stuff in the meantime it started to get really sluggish. I used to do exactly the same thing on my N6 and I could never tell that file copying was running in the background. I checked Kernel Auditor and it was showing temps ~50C and the cores were all being capped around 5-600MHz.
I've tried the stock ROM (stable and beta) and EPIC, and Lineage/RR. It seems to be a bit worse on the latter two (Antutu won't go above 100k, but it's like 140k on the MIUI ones) for some reason, but it's an issue on all of them.
gavin19 said:
Did you ever get any further with this? My phone idles at ~35C. I read a review that said throttling begins at ~40C so I get throttled when I do virtually anything.
I've only had this thing 2 days and the performance has been worse than my old Nexus 6 because the cores keep getting capped very low. I was copying some backed up files over WiFi from my PC. It was lots of small files so it was running for 20 mins or so. When I was trying to do other stuff in the meantime it started to get really sluggish. I used to do exactly the same thing on my N6 and I could never tell that file copying was running in the background. I checked Kernel Auditor and it was showing temps ~50C and the cores were all being capped around 5-600MHz.
I've tried the stock ROM (stable and beta) and EPIC, and Lineage/RR. It seems to be a bit worse on the latter two (Antutu won't go above 100k, but it's like 140k on the MIUI ones) for some reason, but it's an issue on all of them.
Click to expand...
Click to collapse
I have absolutely gotten further here I have managed to get throttling completely disabled actually.
The highest temp the CPU got to was 42 degrees Celsius after running Dolphin for 2 hours straight.
There is no need for thermal throttling on this device at all, hardware does a good enough job clearing the heat.
To stop the thermal throttling you need root access.
Use ES File Explorer from the play store and enable root access
Navigate to root and look for Folder system/etc and find file called thermal*******.*** ( I don't remember what it's called )
Cut this file from this location and paste it into another directory. I moved it to the sdcard for easy access. This way you can move it back if you do not like the results.
I have not experienced any overheating with this, also the battery doesn't drain like crazy. Performance is greatly improved with speed matching the Snapdragon 835 in a few scenarios.
Oh yeah restart the phone after you move the file so it can register the changes. Clock the cores appropriately with Kernal Auditor to make sure it can run at full blast when it needs to. On demand is way faster than interactive.
Cheers. I actually read the links you posted and renamed the conf file. After a reboot it was flying. The problem isn't so much the throttling, it's that mine idles at ~35C already, so it was getting capped when I did virtually anything. If I run Antutu 2-3 times in a row and check the temps in Kernel Auditor it can be in the low 60s. Using other temp apps (CPUTemp) it only shows about 45C tops.
It definitely does feel pretty damn warm since I don't use a case. but I'd love to know what the 'real' temp was. I tend to believe the lower one since I got the 45C warning when using EPIC and that's exactly what the app said. it was.
My Antutu scores increased substantially too. I was sometimes dipping down to 80-90k but I regularly get ~140k now, even 160k once. I know not to go by those scores but when I could never even get above 100k it was a concern.
gavin19 said:
Cheers. I actually read the links you posted and renamed the conf file. After a reboot it was flying. The problem isn't so much the throttling, it's that mine idles at ~35C already, so it was getting capped when I did virtually anything. If I run Antutu 2-3 times in a row and check the temps in Kernel Auditor it can be in the low 60s. Using other temp apps (CPUTemp) it only shows about 45C tops.
It definitely does feel pretty damn warm since I don't use a case. but I'd love to know what the 'real' temp was. I tend to believe the lower one since I got the 45C warning when using EPIC and that's exactly what the app said. it was.
My Antutu scores increased substantially too. I was sometimes dipping down to 80-90k but I regularly get ~140k now, even 160k once. I know not to go by those scores but when I could never even get above 100k it was a concern.
Click to expand...
Click to collapse
Yeah I'm thinking Xiaomi severely limits the thermal threshold to improve battery performance.
It's kinda all they care about in Japan for some reason.
Makes for some great performance improvements without the thermal settings being active.
This setting change is almost necessary of you need some heavy work done.
Glad you were able to get this changed.
i remove thermal_8896_blabla.conf...
Honestly device become too hot for me.... backplate change during my game (Battle Bay), very different sensation... reinstall immediatly *.conf... Finally i have decent perf and cold phone and very good battery life... no more...
My opinion !
lesscro said:
i remove thermal_8896_blabla.conf...
Honestly device become too hot for me.... backplate change during my game (Battle Bay), very different sensation... reinstall immediatly *.conf... Finally i have decent perf and cold phone and very good battery life... no more...
My opinion !
Click to expand...
Click to collapse
I think our best solution would be a modified .conf file that increases the thermal threshold as opposed to completely removing it.
Until this solution is available then this is our only choice.
i agree... i think with a ROM kitchen mayve this fil can be readable... anyway @ this point, we can only hope somebody dectypt this file to support various cool modification available over XDA...
Edit /
it seems HTC make same stuff... here it is a guideline ot example...
https://forum.xda-developers.com/showthread.php?t=2455596
lesscro said:
i remove thermal_8896_blabla.conf...
Honestly device become too hot for me.... backplate change during my game (Battle Bay), very different sensation... reinstall immediatly *.conf... Finally i have decent perf and cold phone and very good battery life... no more...
My opinion !
Click to expand...
Click to collapse
I had the same issue. I was getting 165k+ in Antutu but the phone would get uncomfortably warm when doing multiple passes, or gaming for extended periods.
In the Thermal section of Kernel Auditor, I enabled the Core Control and Temperature Throttle options and the phone still gets warm, but only as warm as you'd expect. I still get ~155k in Antutu consistently and the performance in general is still very smooth. I have the CPU governor set to ondemand, and the GPU governor to simple_ondemand. All other KA settings are default.
One other thing I always do is to reduce the Window Animation, Transition Animation and Animator duration scales to .5x (1x by default). It just makes the phone feel snappier in general. Settings > Additional settings > Developer options (MIUI-based).
I'm using the latest EPIC ROM. Using RR/LOS I couldn't replicate the same high Antutu scores consistently for some reason. I quite like MIUI after years of using CM and CM-like ROMS anyway.
already reduce animation x0.5... MIUI use a lot of this animation with complex and (very long calcul) then reduce this number make device seems much faster... anyway, u right...
A custom kernel for miui base... based on Dragon XIA exist in MI5 thread... only need to play a bit to make universal... with all source we can make somthing, but no have time to play with all tutorial available on XDA or Youtube...
Only way to make device much smoother and battery friendly or Perf/Warm destructor...
Some background on the Nexus 6 that I've owned for 5+ years. Battery life was fairly stable for ~3 years. There were occasions where I played Clash of Clans while quick charging that the phone got scorching hot. So hot that I couldn't hold it against my skin for more than a few seconds. After regularly doing that for a while, the battery degraded to less than half its original capacity.
I bit the bullet and bought a replacement battery. I made sure to get a good quality one, not a cheap Chinese knockoff. I tested the capacity of the new replacement battery and it was close to the original battery's new capacity. However after about a year of clashing and quick charging the phone to stove-top temperatures, the replacement's battery capacity degraded severely.
My friend's N6 suffered similar battery degradation during a road trip while he was charging it in the car, using map GPS, and playing music. The phone got so hot he had to hold it in front of the AC to keep it running.
I like the screen enough to where I'm considering replacing the battery again. However this time I want to prevent it from overheating. Is there a way to disable quick charging in the firmware? Which firmware aggressively throttles CPU to keep temperatures down?
chefp said:
Which firmware aggressively throttles CPU to keep temperatures down?
Click to expand...
Click to collapse
Not shure if this is what you want, but I implemented power profiles in LineageOS 15.1 and 16.0.
You could use the Effcient or Power Safe profile in situations like you mentioned.
Why not simply use a power adapter that cannot deliver much power?
And not wireless charging - that always creates more heat.
Elektroschmock said:
Not shure if this is what you want, but I implemented power profiles in LineageOS 15.1 and 16.0.
You could use the Effcient or Power Safe profile in situations like you mentioned.
Click to expand...
Click to collapse
That sounds great. My N6 is currently running Lineage 14 and I only see Power Save. Is the Efficient profile better? Power Save makes the phone run quite slow. It'd be nice to have a profile that adjusts performance based on temperature. When it's cool it runs faster, and as it heats up it slows down.
runekock said:
Why not simply use a power adapter that cannot deliver much power?
And not wireless charging - that always creates more heat.
Click to expand...
Click to collapse
I use a standard 10W charger at home (5v @ 2.x A). However when I'm on the road, visiting friends or traveling, I may have to borrow someone's charger, and it might be a fast charger. It would be better if the phone throttled its charge rate based on temperature.
chefp said:
That sounds great. My N6 is currently running Lineage 14 and I only see Power Save. Is the Efficient profile better? Power Save makes the phone run quite slow. It'd be nice to have a profile that adjusts performance based on temperature. When it's cool it runs faster, and as it heats up it slows down.
I use a standard 10W charger at home (5v @ 2.x A). However when I'm on the road, visiting friends or traveling, I may have to borrow someone's charger, and it might be a fast charger. It would be better if the phone throttled its charge rate based on temperature.
Click to expand...
Click to collapse
Oh I can't remenber what the Profiles where on 14.1. It's too long ago and 14.1 is far outdated. Profiles in 15.1 and 16.0 are totaly different to 14.1.
I guess a profile based on temperature wouldn't work properly, but we already have thermal limiting. That means the cpu / gpu is throtteld if a certain temperature is reached.
The charging rate is already based on temperature. But fastcharging is always generating more heat then normal charging. If you would limit it to the same temperature levels then standard charging it wouldn't be fast charging.
Elektroschmock said:
Oh I can't remenber what the Profiles where on 14.1. It's too long ago and 14.1 is far outdated. Profiles in 15.1 and 16.0 are totaly different to 14.1.
I guess a profile based on temperature wouldn't work properly, but we already have thermal limiting. That means the cpu / gpu is throtteld if a certain temperature is reached.
The charging rate is already based on temperature. But fastcharging is always generating more heat then normal charging. If you would limit it to the same temperature levels then standard charging it wouldn't be fast charging.
Click to expand...
Click to collapse
Thanks for the info. Is there any way to disable fast charging via firmware, or is that locked in by the hardware?
chefp said:
Thanks for the info. Is there any way to disable fast charging via firmware, or is that locked in by the hardware?
Click to expand...
Click to collapse
Could be limited in firmware but I guess you have to do it yourself.
Elektroschmock said:
Could be limited in firmware but I guess you have to do it yourself.
Click to expand...
Click to collapse
Would I need to build a custom kernel, or could I send commands to a device in /proc to disable fast charging? I do app development but not familiar with the inner workings of this in particular.
Thanks bud
chefp said:
Would I need to build a custom kernel, or could I send commands to a device in /proc to disable fast charging? I do app development but not familiar with the inner workings of this in particular.
Thanks bud
Click to expand...
Click to collapse
Kernel needs to be changed
This Nexus 6 has been running LineageOS 16 for the past 6 months and the power profile is vastly superior to both Lineage 14 and stock ROM. Great work @Elektroschmock on the improved power profiles.
I'm sure there's a custom kernel out there that will let you manually set the thermal throttle temperature. They really pushed the 28nm process to the limit on the Nexus 6 the clock speed of the CPU is 2.7ghz that probably explains why the phone gets so hot when you play Clash of Clans. I don't know what the Krait 450 cores equates to but most of Qualcomms quad core CPUs on 28nm are maxed at 1.4ghz. I'd set the CPU clock speed to 1.8ghz max and lower the graphical settings in the game that should help your heating issues.
Look guys just this year I realized what's causing the Nexus 6 to overheat soo bad look at these pictures in the link below it's because Google was Soo stupid enough to put the CPU right under the battery actually the battery is right on top of the CPU I'm like why the hell did they built the phone like this. If the CPU was far away from the battery the device would not get sooo hot and causing the battery degrade quickly because of all that heat.
https://www.ifixit.com/Teardown/Nexus+6+Teardown/32877