Ok so how in the world are these people getting such a high overclock? I've been doing some research and I just cant figure it out.
Check this link: http://www.greenecomputing.com/apps/linpack/linpack-by-device/ and scroll down to the eris section. There is one guy in there who actually pulled off a 864MHz Overclock. I know thats a hard thing to do because the highest I've ever got was 760MHz and that lasted like 30 seconds before my Eris just gave up. I've accedintly put my phone in the 800MHz range and it just froze instantly. So far the highest stable range has been 748MHz.
Does anybody now something I dont? Is there a trick to getting that high of an overclock with the Eris?
From what I understand, there's a range in the stable clock cycle range that any chip/processor can run at. When the Eris was built, the "sweet spot" (stable) speed was apparently 528MHz (although this certainly could have been selected for marketing purposes too).
Most, but not all, Erii can run safely at 710MHz and be stable. However, we have seen instances where folks have installed ROMs that were overclocked to 710MHz as a default and their phones would not complete booting-up.
Others have indeed "pushed the envelope" by running in the high 700s and even in the high- to mid-800s as you've reported. However, there is usually a cost associated with doing this in terms of decreased life-span of your CPU. That being said, there are some members that have reported having a stable phone running 800MHz or higher. Your mileage will vary, as you have seen -- it really depends on your phone.
Cheers!
I can run 806 just fine, but most of the time I just choose to run at 767 or even 748, mainly because I don't need *that* much speed versus the larger battery drain at such high speeds.
Flashing GB has recently given me the ability to OC to 806, haven't tried any further.
Well, there are two things going on.
The first is that your phone hardware is like any other macroscopic object in the universe - they have variable characteristics. Go to the store and look carefully at the apples they have for sale - pick a given variety, and you'll notice that every one of them is just slightly different from the next.
If you were to zoom in and have a look with a good microscope at the transistors in your processor chip - you would first notice that: (a) there are millions of them!, and (b) they all look very similar, but are not exactly identical. That's just the nature of things - the manufacturing processes have some amount of (hopefully well controlled) variations.
But, when it comes to computer chips executing software instructions, we definitely want them to all behave identically. So, what to do? The answer is, run them all at a sufficiently low enough speed (and a large enough voltage) that the small natural variations from transistor to transistor never make a difference in how the outputs from those transistors are interpreted.
You've heard the expression "timing is everything", yes? Nowhere does this expression apply better than in computer chip design. I'll use a stupid analogy to illustrate how this works.
Suppose you had a marching band ... not like the ordinary kind, but instead, a band full of morons. So stupid, in fact, that you teach them to play songs like this:
"You nearest two neighbors will hand you a note just before each beat of the kettle drum, and you will decide based on those notes what note to play yourself after you hear the next kettle drum beat - and then you will hand that note to your neighbor".
In this analogy, each (transistor) logic gate in the chip is a moron band member, and the kettle drum is like the system clock.
Well, each moron (transistor logic gate) in the band will need to take some time to decide what note to play next. And it is plainly obvious, that if the moron's neighbors (other morons/gates) don't hand their notes off by the time the kettle drum beats, the wrong decision will be made. Chip designers call this "setup time".
Also, since we presume that the band members are morons, they actually need to some amount of time to stare at the notes from their neighbors to make up their mind - sometimes so slowly that the beat of the kettle drum has already been heard some time ago before they make up their mind. If the neighbor moron band members were to "yank their notes away too quickly", the receiving moron band member (logic gate) might again make the wrong decision. Chip designers call second sort of timing measurement "hold time".
So, this is a very simplistic view of chip design: the designer needs to make sure that the inputs (notes) to every gate (moron band members) arrives well enough ahead of the clock (kettle drum beat), and stay stable for a short period of time after the clock (kettle drum) beat. And they also have to consider how slowly each gate (moron) can "make up his mind" - because of course, that introduces delay in passing off information to other gates (morons) at the next beat of the clock (drum).
If you followed this analogy closely, the question might have also occurred to you, "what happens if the morons in the band don't all hear the kettle drum beat at precisely the same time?" In the analogy to chip design, this is the problem of clock distribution - because at each moron (gate), the decisions are made when they individually hear the kettle drum (clock) beat. So, there could be some major trouble if a moron (gate) was supposed to receive notes (signals) from other morons (gates) that were hearing the kettle drum (clock) either much to early, or much too late, compared to their neighbors.
Now, marching bands are only a little bit like this, especially since we said in our example that only nearby neighbor morons (gates) were involved; but in chip design, both clocks and signals may need to be passed great distances away, not just to nearest neighbors.
A major part of chip design revolves around exactly these concepts: trying to compute exactly what the "setup", "hold", and "delay" time min/max values are for millions and millions of gate and signal paths in the chip, and also knowing exactly how long it will take for the signals and clocks to travel from their source to destination(s).
If only a single one of the millions of morons (gates) gets this wrong, the whole song is ruined.
So, it should be clear that if you run the system clock really, really slowly, you generally won't bump in to any setup or delay hazards (hold is a little trickier, but we can ignore that). The clock beats so slowly that signals have plenty of time to reach their destinations, and also the amount of delay through each gate is negligible compared to the long amounts of time that using a slow clock grants you.
But as you increase the clock faster and faster, you start shaving away available time for signals to get to their destinations, and come closer and closer to one of these hazards - a "setup" or "hold" violation. Not only that, but the delays across the chip - which are negligible for a slow clock - start to become really important.
Now, I spent a lot of words up there to illustrate something: the timing problem only very weakly depends what software is running on the phone, it is a function of the hardware alone. You can't "install some software" to make this problem go away. Your microprocessor will run flawlessly up until a certain clock speed, and then disaster!.
And that disaster could be the fault of a single transistor out of tens of millions - generally, a transistor which for some reason, is "weaker" than most of it's neighbors - or it has to push a signal through a line which is oddly more resistive than it should be - and therefore slower.
The second thing to be aware of is that these benchmarks are being run on a multitasking operating system - if you run them 5 times in a row, you will see that you get a different benchmark value each time you run them - because other activities on the phone and the kernel's scheduler conspired to give your benchmark app slightly less or slightly more total attention during the elapsed (wall) clock time of the benchmark.
So, since that website records the "best of the best" - make sure you run your benchmark twenty to fifty times, see if you can diddle the oom_adj value of your process while it is running, and delete all other applications from your phone so that it is the only thing running.
To illustrate that there's no "magic" going on here, I'll give you a concrete example. Two days ago I ran that Linpack app on my Eris. Here's what I did:
OS: GSB v1.2
min cpu = 748 Mhz
max cpu = 748 Mhz
governor = performance
JIT on
killed off most idle apps
And I got linpack scores that varied from 4.8 to 5.1 over two or three runs.
Now, let's compare (the best of) those results to the ones reported in the Benchmark results, but scaled to a different frequency:
(844 Mhz / 748 Mhz) * 5.1 = 5.75
Note that this is plenty close the the value reported at 844 Mhz.
If you want to convince yourself that your phone is fine, set the cpu speed min=max = whatever. Then run the benchmark a couple of times, and compare your result
(844 Mhz / whatever ) * your_best_result
And you will see that your phone is no "different" than the best Eris out there - except that it can't run at 844 Mhz. That latter part is just the luck of the draw.
bftb0
Not all CPUs are created equal. Some are stable at higher frequencies than others. This because many of the steps in CPU production rely on chemical processes. Doping, silicon wafer growth, electroplating, etc. Manufacturers use a technique called CPU binning to help them sort out the better chips.
Where I learned this:
http://www.tomshardware.com/picturestory/514-intel-cpu-processor-core-i7.html
@bftb0...that was beautiful...
If you're going to try higher rates, leave logcat running and watch for errors.
I love that analogy. Mostly because it's fun to make fun of morons, and the more the better!
bftb0, could I have your permission to repost that (up through "and therefore slower.") on FaceBook? I will note before the quote that this applies to any kind of computing device, but I wouldn't change anything you said. I would, of course, also give a linked credit to you, this thread, and XDA.
I was going to ask you in a PM, so I didn't put you on the spot in public, but you must have used to get way too many PMs since you disabled that.
I won't be offended if you say no, just thought I'd ask.
Actually most of those are faked.
There used to be 1ghz scores for the eris. They're quite easy to fake. While some phones can get quite high due to the way CPUs are processed... the linpack website is incredibly easy to fool.
roirraW "edor" ehT said:
could I have your permission to repost that (up through "and therefore slower.") on FaceBook? I will note before the quote that this applies to any kind of computing device, but I wouldn't change anything you said. I would, of course, also give a linked credit to you, this thread, and XDA.
Click to expand...
Click to collapse
Sure.
+10char
bftb0 said:
Sure.
+10char
Click to expand...
Click to collapse
bftb0, I never took the time back then to say thank you for your explanation. I'd like to do that now. Thank you. Obviously I know more about Android and the phones its installed on now. I have a better understanding of this subject and others you have helped with.
Also I haven't seen you around lately. I certainty hope your ok and hope to see you around again.
DINC|CM7|INCREDIKERNEL
I see him all the time. Well I don't actually see him but I do benefit a lot from his advise and insites. Also I've been able to run my Eris at 787mhz without issues but as a norm run at 710mhz.
Related
As some of you may know, the 45nm QSD8650A due out later this year can run at an incredible 1.3Ghz, 30% faster than the current Scorpion core used in the Nexus One. I was, of course, getting kind of jealous of this speed, and wanted to see if it was possible on the Nexus One. Since the model number hasn't changed much (from QSD8x50 to QSD8x50A), I thought that the "A" might only indicate a die shrink and not any significant hardware changes.
Warning: the following information is for kernel developers!
It appears to be a possibility. I dug through the kernel source of the Nexus One and I've discovered that the QSD8250 in the Nexus One might be able to reach ~1.267GHz. I point you to the following file in the kernel source:
http://android.git.kernel.org/?p=ke...f5dab31e6ffece;hb=android-msm-2.6.29-nexusone
Near the beginning of the file, a list of frequencies is given. Starting from 384MHz, the frequencies start basing off a PLL called SCPLL, and increases in multiples of 38.4MHz. If you look at the table, the frequency defined in each row that uses SRC_SCPLL is 38400*sc_l_value (sc_l_value is also defined in the table, in hex).
If you look at 998MHz, it's 38400*0x1A = 998000, which is the max clock of the Nexus One. Now take the closest speed to 1.3GHz if you continue the 38400KHz increments. 1.267GHz should be 38400*0x21, or 38400*33. Where else do we see 33 in the code?
The function if scpll_set_freq() contains the following simple code for bounding sc_l_value. Note that the maximum value is exactly 33, and not 26 (0x1A)! Also, the minimum value is 10, which matches the lowest SCPLL speed, 384000.
Code:
if (lval > [b]33[/b])
lval = [b]33[/b];
if (lval < 10)
lval = 10;
33*38400 (1.267GHz) nicely corresponds with the maximum 1.3GHz of the 45nm Scorpion. Qualcomm rounded 998MHz to 1GHz so there's no reason why they wouldn't round 1.267GHz to 1.3GHz.
CPU voltages are also defined in the table. Some previous versions of acpuclock-scorpion.c had the CPU running at 1.3 volts at 998MHz, but now it's running at 1.275 volts at 998MHz. What we know from that is that the processor can handle up to 1.3 volts (or possibly more). If the processor can't go above 998MHz at 1.275 volts, we know we can (somewhat) safely increase the voltage to 1.3, and unsafely increase it above that.
There is, of course, a comment saying: "output of scpll 128-998 MHZ," which is contrary to the bounds defined in scpll_set_freq(). If this really is the case, overclocking might still be possible, but it would be harder.
What would really help is if someone sent us detailed Qualcomm documentation for the QSD8250/Scorpion core. Don't post it publicly, as Qualcomm is Cease and Desist happy about such things.
My Nexus One is currently not unlocked, as it's waiting for an RMA, so there's no way for me to develop/test any of this. Swetland would also know a lot about this, but who knows what kind of NDA he is under from Qualcomm
It might be as simple as appending a few lines to the table. Keep in mind that the last value (vdd/voltage) might need to be adjusted:
Code:
{ 1036800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1B, 0, 1300 },
{ 1075200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1C, 0, 1300 },
{ 1113600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1D, 0, 1300 },
{ 1152000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1E, 0, 1300 },
{ 1190400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1F, 0, 1300 },
{ 1228800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x20, 0, 1300 },
{ 1267200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x21, 0, 1300 },
{ 0 },
I also found the exact commit where the Scorpion was changed back to 1.275v from 1.3v:
http://android.git.kernel.org/?p=ke...ff;h=7fcffb1e4554e1e364e994e5ce1ef7e471422ebf
The commit was made after the holiday N1s were passed out so we can probably conclude that it's reasonably safe.
Edit:
Just an update: Qualcomm's code in Codeaurora reveals that there is an eFUSE defining the max clock of the processor, read from a certain address, and as predicted, 1267200 is indeed a valid maximum speed for some versions of the Scorpion (this is, more likely than not, the "1.3GHz" quoted by Qualcomm). It also explains the Liquid's situation. The Scorpion core in the Liquid is probably not underclocked (at least not any more than the Neuxs One is underclocked in relation to the 8x50a), but intended to run at 768MHz max.
https://www.codeaurora.org/gitweb/q...c;hb=7d031492392a410d4814b6e104f53d55b0ae499b
Code:
switch (tcsr_spare2 & 0xF0) {
case 0x30:
max_acpu_khz = 768000;
break;
case 0x20:
case 0x00:
max_acpu_khz = 998400;
break;
case 0x10:
max_acpu_khz = 1267200;
break;
default:
pr_warning("Invalid efuse data (%x) on Max ACPU freq!\n",
tcsr_spare2);
goto skip_efuse_fixup;
}
I feel that the people who have the knowledge required to make these tweaks can experiment with them responsibly. I do not encourage releasing a kernel publicly capable of reaching higher speeds or voltages.
Really hope this is possible...you do great work!
Wow that would be sweet
Don't think we'd need it soon but man, just the bragging rights
Very interested in this and nice find.
Almost entirely possible from a hardware standpoint.
And I bet that is exactly it, a change in manufacturing process... the end result being a lower voltage requirement and stability at higher speed (and a longer run time at lower clock speeds).
Don't know how much of a boost we would see performance wise... lower battery life of course and more heat. Not a bad thing to start looking at however as who knows, we could be crying for a bit more speed in the not too distant future.
This sort of thing (pushing the CPU beyond the rated/validated max frequency and voltage) definitely falls in the "could permanently damage the hardware" category. Pushing the voltage out of spec tends to lead to fatal L2 cache errors, etc just for starters.
swetland said:
This sort of thing (pushing the CPU beyond the rated/validated max frequency and voltage) definitely falls in the "could permanently damage the hardware" category. Pushing the voltage out of spec tends to lead to fatal L2 cache errors, etc just for starters.
Click to expand...
Click to collapse
Totally agree there.
KiD0M4N said:
Totally agree there.
Click to expand...
Click to collapse
U can brick your nexus by flashing too. But we do it anyway.
So lets start to overclock
DocRambone said:
U can brick your nexus by flashing too. But we do it anyway.
So lets start to overclock
Click to expand...
Click to collapse
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse
The small fraction that do this will never have a impact on the manufactures.
I'm with swetland here. Overclocking the CPU up to its rated max (Like the G1) is great, but hacking the kernel to push the CPU past its rated limit is just asking for trouble in a device with tolerances as tight as the N1, remember that in a desktop machine if you OC past the rating of the CPU you are always told to ensure you have sufficient cooling and have MB's that can handle the Vcore increase, no such thing is possible here.
Do you really think people are going to go "oh well I knew the risks" when their N1 fails after 6/12/18 months if it's been OC'd or do you think they're going to complain bloody murder on forums, making the image of the N1 even worse?
We're already trying to defeat the bootloader relock security. The combination of these two things has great potential to ruin Google's good work with HTC.
All IMHO of course
I have to disagree, HTC do not care about XDA's efforts.
As long is not a market app that overclocks nexus they wont notice.
swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse
The warranty policy position is totally understandble, especially if you consider the hoardes of people that have bricked their devices on this forum, mostly due to thier own massive ignorance and inability to read
Personally I don't expect any warranty whatsoever after unlock, but I'm the kind of a nerd that has tons of bricked stuff at home after playing around with it too much
I just hope that HTC will be willing to fix obvious manufacturing errors (like dust under the screen, broken pixels) despite phones being unlocked. Just because they have the right to not fix it, there is no need for them to be asses about it. If someone tries to RMA a device with a cooked QSD in it due to overclocking, they deserve to be turned away.
Now if we can only be allowed to flash the splash screen, w/ the padlock superimposed on top if unlocked
I think people who have purchased and own a device have the right to do whatever they want to that device. And if they want to share what they are doing with others, I am interested to read it. As long as the risks involved are made clear, I see no harm in sharing. The vast majority of users will not attempt this anyway unless it is shown over time to be safe.
I'm with swetland...
Anybody who thinks there is a small fraction of people who are on these forums who may brick their phones is a fool. Just think about how many idiot post are posted in the wrong section & how many people can't follow simple instruction to flash their phone. I think for every idiot that post that can't follow simple instructions, there are probably at least 10 people who are lurking and not posting at all. I lurked for as long as I could and didn't sign up until I had to so I could download a file or view a screenshot. The market has made the idiots flock to XDA by posting information in the market apps themselves or the comments. Just look at the comments that say "What is root and how do I get it? Hit me up at [email protected]"
The point of this is, This forum is filled with both some of the smartest people I have come across and the dumbest. Either one there are a lot of. If there is a software update that pushes the phone faster, people will flash it. Even if they have been warned it could fry their processor (Like every post about flashing your phone could brick it).
I don't mind pushing the processor to the speed it was designed to run at, but I wouldn't want to push it any faster. How many fried $500 phones do you think it would take before they start to notice. It sure didn't seem to take google too long to notice Cyanogen and he wasn't even bricking phones.
Certainly, it's your phone and nobody's stopping you from doing anything with it. I'm less concerned about what people who are fully aware that they're pushing the hardware past its design limits do than what happens when somebody releases supercool-overclocked-tasty-rom.img or whatever and a pile of early adopter types who enjoy trying the new shiny and are pretty good at ignoring any and all warnings end up doing to their hardware.
It's been a long road to get to the point where these devices are shipping with unlockable bootloaders as a feature, not an exploit. We're certainly not done yet, as can be seen based on concerns about the warranty language around unlocking, etc.
I'm simply asking that people consider that actions taken here will impact future devices and possibly show some restraint when appropriate. I'd like to enable future devices to be *more* open, and will continue to work toward that goal, but the actions of this community, and others who create modified system images and make them available to broader userbases *do* have the ability to make my work much, much harder, or much, much easier.
swetland said:
Certainly, it's your phone and nobody's stopping you from doing anything with it. I'm less concerned about what people who are fully aware that they're pushing the hardware past its design limits do than what happens when somebody releases supercool-overclocked-tasty-rom.img or whatever and a pile of early adopter types who enjoy trying the new shiny and are pretty good at ignoring any and all warnings end up doing to their hardware.
It's been a long road to get to the point where these devices are shipping with unlockable bootloaders as a feature, not an exploit. We're certainly not done yet, as can be seen based on concerns about the warranty language around unlocking, etc.
I'm simply asking that people consider that actions taken here will impact future devices and possibly show some restraint when appropriate. I'd like to enable future devices to be *more* open, and will continue to work toward that goal, but the actions of this community, and others who create modified system images and make them available to broader userbases *do* have the ability to make my work much, much harder, or much, much easier.
Click to expand...
Click to collapse
Very true. Unfortunately, I'm not sure if there's a whole lot that can be done about that. We can limit what happens here to be sure, but some jerk dev, somewhere, will ignore the warnings and "give the people what they want" to make a quick buck.
Im not sure if this is really necesary...
I think with 1ghz and 512mb ram we have enough for so long...
And of course, the only thing i like from the iphone, there is no reason to "put on steroids" a pda, just clean and improve the OS and optimize the apps...
The simple solution is to just make your hardware safe from software damage. Shut the thing down if it goes far enough out of spec to potentially damage something... like desktop CPUs will shut down when the temperature goes too high.
swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse
granted, this is complete speculation on my part. but I just find it farfatched that HTC cares much about people who brick their devices. It doesn't effect HTC's bottom line in any way. their policy is that if you gain access to functions that have the potential to damage the device's hardware, your warranty is voided. nobody can credibly blame HTC when someone overclocks ther device and it gets fried, so they lose neither money nor PR damage.
of course, anyone who promotes a hack for a device without properly disclosing the risks is irresponsible and wrong. likewise, so is someone who mods their device without engaging in the research to properly decide if it is worth the risk to them persoanlly.
as far as persuaduing HTC to be more open with their devices, I think it might be a little idealistic to assume that any device manufacturuer will ever change warranty policy regarding modding. making it easy to unlock the bootlaoder is nice of them, but its also of no risk to them because they're not liable for what happens to it if you do that. they will never take on added risk by exapanding their warranty coverage for people like us no matter how many people brick their phones or not.
I'm curious about the state of fine tuned overclocking on the note.
Of course, we have Da G's OC Kernel, and a couple roms.
But i've never been so unlucky when it comes to receiving some free performance via overclocking.
I've been blessed with a solid piece of silicon on my transformer and my desktop setups.
I find that even at 1.72ghz, i FC every 20-25 minutes or so. Just enough to make me want to avoid OCing it.
At 1.78 it's worse, and although i've heard that the majority of users have no issues at 1.83 ghz, i crash hard at that settings--within a quarter-minute of applying it.
I've tried different governors, and had more luck with smartassv2. I have a feeling that i just received a mediocre piece of silicon.
I only have a couple options-- i've had other issues with my note--namely the buttons; soft keys, as well as hard, and display brightness--unfortunately im just past my 30 days to return the note, so i'd have to replace it through Black-Tie Protection....i have no idea how this even works.
The other option is to bump up the voltages, but in SetCPU, there are no options, and CPU Master is the same. The only app I've found that even lists voltage options is System Tuner Pro, and while i'm not fond of the UI, i could deal with it.
Edit:
It turns out, bumping up the voltages @ 1.83ghz to 1375mV seems like it buys me a few seconds more before i crash and burn, but this could be a placebo affect.
So, the pupose of this thread is two-fold:
A: Find out if voltage adjustment is a function of the app, and a logic board component.
B: Find out if voltage adjustment must be supported at the kenel and/or ROM level in order to function, and the settings i'm changing are just dummy settings without said support.
2.
A: Find out how much variation on overclocking yield is standard.
B: Poll and share the results.
it is non sense having a poll for that because although we have the same device, still they are not the same if u know what i mean. stop overclocking if it crashes unless you want your phone to die, or just get it replaced with another one and see if it works fine. 1 question, why you need to oc?
This thread is for discussing overclocking methods, settings, support, and to answer my questions about the above listed specificity.
The poll is meant to survey our (us @ the LTE Galaxy Note forums on XDA) sample (albeit, a small one) to find out where our numbers fall. Unless we have a volunteer to read the thread every day, and report back on how many users are stable @ the clock speeds listed above, a poll is the most efficient, concise, objective, and standardized method to gather such information via forum.
Us non-cyborgs (organic humans) just don't do well when it comes to looking at a ton of numbers and extrapolating 411 from 'em over, and over, and over again.
*********
I've read on several ROM forums that only certain apps utilize or dual cores. go to sys/devices/system/cpu/cpu1 there is a file there. When using one of the above said apps it populated cpu1 with freq folders etc, changes that one file from 0 to 1 enabling it. without one if these apps there is no freq tables for cpu1.
****my question: using Linux and cpu i ran speed tests. Over 70 tests in total. There is zero performance difference in using one app versus another versus cm performance cpu menu. I understand how it looks like two cores are only utilized from certain apps looking at the folders. However it does not change performance at all. Tests show same speed any way to control cpu. Also feels the same. Is there really a difference our is it monkey say????
Also in my tests i found using "VR" versus sio or noob or cfq to be the fastest. I didn't feel a difference however changing i/o setting.
Sent from my SGH-I717 using xda premium
Their are claims that Intel’s internal handset testing has shown multi-core implementations running slower than single core, however they did not cite any particular chip. If you take a look a lot of handsets on the market, when you turn on the second core or having the second core there [on die], the [current] leakage is high enough and their power threshold is low enough because of the size of the case that it isn’t entirely clear you get much of a benefit to turning the second core on. In some of the use cases they cited, having a second core is actually a detriment, because of the way some of the software engineers have not implemented their thread scheduling properly.......
That being said, one could argue the concept that a single core chip, running a slight overclock, would produce a far better result, than a dual core application. But again, thread scheduling detracts from any governor efforts anyway...IMHO....g
Hum. I would have to agree then that in our case and in my tests dual core doesn't help nor hinder performance results but does appear to reduce battery life. Now these are my tests using two different programs to test performance and using combo of setcpu/system pro/Cm10 performance built in/Tasker to control cpu. I have done enough testing to know that on cm10 roms dual core, or so the sys files indicate, is of zero performance upgrade and appears to drain battery faster.
Sent from my SGH-I717 using xda premium
Yes ...I agree with your findings.
I suppose it's safe too say then, when using the AOSP rom source, within it's normal configuration, that unless development is done beyond the current schedules, the stated performance is well ....overstated ??
Of course , CM is in a constant state of change, and I suppose that after they are finished with the functional repairs, they may focus more on the kernel.
I'd be very interested to see your same tests against another kernel, say flappjaxxx latest JB build.
I do know that he, and several other developers have made some great improvements to the source kernels, and although there will likely always be bugs present, after running my own evaluation of them, the governors are functional and do make at least a perceived difference.
But as you stated, albeit at the cost of battery life.
I choose not to overclock, as I feel that the marginal reward , as proven by your testing , and by testing from several reputable sources, is simply not worth the risk ...g
I agree Greg, i will test other kernels... Samsung ROM is probably the only one i won't test... I also don't overclock, i do under clock at work and screen off using Tasker for battery life. That does help greatly. I'll post back after testing different kernels tonight.
Sent from my SGH-I717 using xda premium
troyolson92 said:
I agree Greg, i will test other kernels... Samsung ROM is probably the only one i won't test... I also don't overclock, i do under clock at work and screen off using Tasker for battery life. That does help greatly. I'll post back after testing different kernels tonight.
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
Excellent....
And I suppose, since this is the Premier development site, that it would be of great value to the community if you could perhaps publish your results here ?
These aspects of the android OS have been of great interest to me for some time.
Without doubt, many other users would enjoy this information as well in forming their decision regarding roms, kernels etcetera.
Thanks to you, for your inspiring thread. I look forward to the forthcoming information ....g
Ok with out posting tons of pics i tested all available kernels (new). Results were the same. No real difference in single core versus dual core...
The following pics show how to know whether the second core is online or not and my results and how i tested this time around... I was more through the first time but results the same.
Sent from my SGH-I717 using xda premium
troyolson92 said:
Ok with out posting tons of pics i tested all available kernels (new). Results were the same. No real difference in single core versus dual core...
The following pics show how to know whether the second core is online or not and my results and how i tested this time around... I was more through the first time but results the same.
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
I am posting pictures for first time hope this turns out.
What do you use to disable the second core? Read this with some interest. Would like to try this with ics Rom. With oc'ing fRom 1.56 to 1.72 i see a consistent jump of 300-400 in my antutu scores. Currently on flapjaxx ics b4.
I know it is just a score, but is your score indicative of the cm builds? It just seems really low.
Here is my 'stock 1.56 speed' with ondemand governor. Want to a get a single core sample.to compare with it.
How interesting ....
I can say that both of your posted results lead toward our initial assumptions, that indeed we are seeing a consistent draw against the systems cores with little or no improvement upon activation of the second core.
Some Time ago, shortly after my note arrived, I began some simple tests with low speed dual core activation. My thought process was simply this.
Slow speed dual core operation (both cores running in the 650mhz range ) would ideally produce a faster process response.
My initial results were favorable, as I had a noticeably quicker device during screen transitions, and even in several multitasking functions.
I even went so far as to create a small script to handle this function for me. I'm no developer, and ultimately I didn't possess the programming skills I needed to complete and implement my script into an actual, flash worthy modification. And based on what we are seeing here , the results provided would indicate that my attempt is flawed due to chip current leakage, if the cores are allowed to ramp to high, and perhaps even the use of improper source schedule interference.
I'm so busy these days, I simply haven't time to explore the low speed theory further at this point.
But perhaps with your test bench already set, a simple test using my concept could be carried out??
As we know, CPU [current] thresholds are plagued by voltage bleeding at maximum CPU frequencies, but the thought has just occurred to me that [current ] bleeding is highly controllable when the CPU is driven at lower voltage inputs. And too combine a reduced frequency with reduced voltage over a multiple core platform, could, or should balance the loss and equal the output levels.
Are you up for another test ??
If so ....I suggest the following parameters.
Core "0" at 600/700 MHz
Core "1" at 600/700 MHz
Governor at "interactive "
Voltage at "-24Mv"
Then we'll see if the theory holds water.
P.S. thanks gents, I'm enjoying the heck out of this thread ......g
Mad383max, look at your folders from my pics to tell if two cores are running. Typically on after market roms one core is running until you enable the second from other software like from my pics.
Will test at lunch. I like this lower voltage idea. If i were a betting man i would guess with speeds you proposed and two cores i would guess similar to higher results. Let's see....
Sent from my SGH-I717 using xda premium
troyolson92 said:
Mad383max, look at your folders from my pics to tell if two cores are running. Typically on after market roms one core is running until you enable the second from other software like from my pics.
Will test at lunch. I like this lower voltage idea. If i were a betting man i would guess with speeds you proposed and two cores i would guess similar to higher results. Let's see....
Sent from my SGH-I717 using xda premium
Click to expand...
Click to collapse
Agreed......
I'm excited to see the results....and thank you !!...g
I have to reflash ROM so pics might be a little awhile. I messed up some things and somehow lost my Google account. reflashing gapps and ROM didn't fix it.
Anyway results were 2600 something at 700 both cores underclocked 25... Slightly more than half of normal speed at slightly less than half clock speed... For kicks i tried 1.5 clock speed undervolted 75 (most my phone will go without lockups) and got 5k results. Best yet.
You are on to something. Less voltage = more speed. I now need to try single core undervolted. Give me couple hours for pics etc.. Got to get phone working with Google again and spend time with wife. She hates me on the phone.
Sent from my SAMSUNG-SGH-I717 using xda premium
No worries Troy. ...
Take all the time you need.....
I do appreciate the excellent testing you have undertaken. I know that the results are going to benefit the community.
And i am highly intrigued by your first run under the parameter set you've chosen...
It's leading down the exact path that i suspected. ..
I'll talk with you soon. ...g
A few additional items that I have failed to consider during my testing, could weigh heavily on our testing results and should be considered during testing.
They are, battery power levels, charger connection and type....(wall/PC), and rom power save levels.
I do know that the android OS will adjust itself during varying power levels, much like our setting the CPU to UC/UV settings, only on a much smaller scale.
I feel its important that we are able to control the input levels in the following way...
Battery to full charge, with no charger connection, and if the cable is needed we use a non powered port. Next would be controlling the rom power settings if the rom contains them, as found in most GB and ICS builds.
If these baselines are met, we should be able to greater rely on the mark scores we are seeing. These variables could explain why we continue to see so many peaks and valleys in scores when two users share the same builds, on like devices.....(speculation)..
Additionally, are we able to control the background processes to the extent, they will remain constant for testing?
Sorry for the rant.....Im just concerned about the ability to quantify our findings once testing is complete.
Ive started some tests on my end as well, and certainly do not want to give you the impression that I expect you to do all of the work.
After all, you did ask first....lol and I feel like Im dumping this effort into your lap.
And please forgive my pathetic punctuation in this post, as my keyboard of choice decided to fail tonight....g
Battery does effect performance greatly.... Also noticed none of the apps to test are very repeatable. Fluctuation seemed to be about 100.
Having issues up loading pics from phone, I'm away from laptop for a few days.
In the end i found -12 v single core to provide the best battery and performance that was equal to dual core. I tried over under voting many differences.... over voting did nothing, under voting a little made small preformance improvements. I believe some of fluctuations are related to app, battery, etc.... In the end it's too say dual core has no speed improvement. I would be cool to test an app that it's specifically for dual core. I am better off without the second core speed is same anyway, and battery is much better. There is definitely voltage leakage..
Let me know what y'all find in your tests....
Sent from my SAMSUNG-SGH-I717 using xda premium
Outstanding !!
I appreciate the hard work !!
So it seems we are better off using the note running a single core and about 12mv under volt.
And I'm of the belief that our second core is rather pointless...unless it can be proven that the second core is absolutely needed to perform a function.
And so far, I haven't found anything I use that requires activation of the second core.
I'll continue my tests, but the way it looks now, Intel is right, and Samsung pushed a dual core chip to this device for nothing more than a market share increase. As it is quite clear that the device does "not " need it to function well, and at a Very respectable speed.
Now we have a quad core version, and I highly question the motivation behind that move, beyond marketing as well.
These statements may offend some, and folks will certainly disagree, but if you want a great running device and great battery life, you need a single core chip ...IMHO ....g
Agreed Greg. Someone will get upset when they do thirty own tests and realize what we see, and what you said, good marketing by Samsung. Numbers don't lie and i did tests as controlled as possible. Even my battery shows in the picks... A true second useful core would have easily bested the single core results. Plus undervolting tella the bigger story...
I must say though. It had been very useful.. My battery life is so much better now!!!
For me the only true performance gain had been from v6 supercharger.
Sent from my SAMSUNG-SGH-I717 using xda premium
Fyi: same exact results using cm9 versus cm10. Neither ROM benchmarks faster than the other as of 9/16 cm9 and 9/15 cm10 builds. Dual core zero performance upgrade.
Tried quadrant again and result very up to 20% back to back so that app is useless to me.
Can someone try a Samsung based ROM. I'm curious add to a difference in roms. just use antutu benchmark and set cpu however you wish to whatever you wish just report cpu clock speed, type of test, and results
Sent from my SAMSUNG-SGH-I717 using xda premium
Out of town this week Troy, but i'm gonna bump it for ya...g
Hello I own the Samsung Vibrant for two years now and even though I was a bit reluctant to overclock the phone at first as new phones were coming out in the market and its (Vibrant's) performance deficit was becoming all the more significant (in comparison to newer phones) I "succumbed to the temptation". At first by a little margin (no more than 20% overclock) but eventually -as I was seeing my phone to be capable for it- for even greater ones. There was a time that I was using my phone at 50% over-the-stock clocks.... those were the days
Eventually -it seemed- as if it somehow starting becoming less and less capable holding the clocks so I started lowering my clock thresholds eventually killing the overclock altogether. Mind you the grand total of the time(s) that I had my phone overclocked (up until then) was not that great...
But then ICS came out with all its fancy tools and the "temptation" overcame me again and as if from a miracle I was able to maintain 50% overclocks like the good ole days (1512Mhz to be exact). To be sure -that time around- that that is a stable clock I devised a slew of different test from extensive software decoding, to 3D and CPU rendering. My phone was rock solid. To address the battery issue I bought an extended battery and all was well in "Vibrant-Ville"...
To my dismay though even though my phone seemed rock solid I seemingly starting losing my overclocking capacity (once again) as I migrated into Jelly Bean, so I said to myself "oh no, no, I'm not going through this again, I'd choose a moderate overclock and I'll leave at that". So I disabled Live-OC, custom voltages, hell even deleted NSTools and used the standard 1.2GHz setting, my battery was better, my phone was rock solid once again and thanks to jelly bean my phone was still fast enough...
Two days ago -though- the ghosts of the past reared their ugly head once again, out of the blue my phone lost its stability. Anytime I was trying to do anything remotely complex and it would reboot (BTW I'm using Helly-Bean right now, using the "Smooth" setting, Smartass governor @ 1.2ghz, pretty standard stuff).
I love this phone but I feel it's nearing its death-bed, what's your opinion guys?
I'll prolly remove the oc altogether but I fear it won't be enough, I fear that instability would start encroaching the 1ghz setting as well one of the days and then it would be game over. I want to avoid this fate at all costs, so anything you could recommend I would try, even changing my rom.
Also to those who used overclocks in the long term what was your own experience?
Thanks for your attention
No response(s)?
Sorry for the bump but I take it none of you guys ever have/had any of the problems I'm describing. Hmm, that means that I was unlucky with my piece of hardware it seems... pity :/
More than likely an aging chip is the case. Personally my phone runs smooth at 1GHz, so I don't see the need to unnecessarily overwork the CPU. After reading your original post, one line stuck out to me in particular. You mentioned that you ran the CPU at 150% for a time, and to me that sets off a red flag. Setting the CPU at 1.5GHz is risky and can cause some major wear on the CPU. Not to say I've never overclocked that high, but I usually only set it that high when playing a high graphics game. Even then, 1.5GHz is not recommended if you wish to use your device long-term. Even 1.4GHz is considerably pushing it. Although our devices can handle it, eventually, they're going to tire out. Now some phones may be able to last longer than others, it depends on the amount of iron in the sand used to make the silicon processors or other minuscule things could play a role. Essentially, it's random. No two chips will be exactly identical nor run exactly the same. So in your case, that may be the case. Perhaps your device really is nearing the its end. Considering that your phone was made to last only a few years at stock speeds, you should still be pleased with how long it's lasted. However, it is understandable if you're upset with this. The only thing I can suggest is to not overclock anymore and to try and keep its temperature low. Perhaps try undervolting? But if you want your phone to last, don't overclock (if your phone's processor is already starting to fail at 1.2GHz, when it used to run rock solid at 1.4 or 1.5GHz, then you definitely need to stop overclocking entirely). More than likely you won't hear other Vibrant users discuss similar problems because they've already moved on to new devices, before the long-term effects of high overclocking began to take its toll. But if you do a little research, you'll find other users on other devices having similar problems to what you are having.
Wish you the best in your efforts, and hopefully you'll get a year or two more out of the device... Hopefully someone will come forward with a better recommendation/solution to your problem. Since I pretty much stated what you probably already knew.
I'm not for overclocking, nor have i overclocked my vibrant.
With that being said, i have never had any performance issues, and I'm having difficulty recalling any issues with stability either..
I hope you treat your new phone with more respect..
I'm sure it will live you much longer for it.
Sent from my amazingly stable SGH-T959 using SlimICS
Well, I was trying to tweak the CPU frequencies, but they always seemed to be overrite. To put the numbers into perspective, let's say I changed the max frequency to 787 MHz. If I start switching between apps, I'll see the max frequency ramp up to 1.44 GHz and then back. I tried changing input_boost_ms to 0 but didn't work.
My guess is that there's a daemon running somewhere. Any ideas?
Thanks
Here's my advice. Don't play around with these things. In this day in age there is simply no need to play with frequencies and whatnot. Gone are the days where oem's couldn't make a decent kernel. It is ridiculous to see how many people seem to think they're an expert on kernel's and uc/uv etc. There is a reason that the frequencies are set and certified by google before release. You're not going to gain anything by touching them. Our phone's are so powerful there simply is no need to waste time potentially damaging your device.
markbencze said:
Here's my advice. Don't play around with these things. In this day in age there is simply no need to play with frequencies and whatnot. Gone are the days where oem's couldn't make a decent kernel. It is ridiculous to see how many people seem to think they're an expert on kernel's and uc/uv etc. There is a reason that the frequencies are set and certified by google before release. You're not going to gain anything by touching them. Our phone's are so powerful there simply is no need to waste time potentially damaging your device.
Click to expand...
Click to collapse
Hey, but what's the fun in that XD
Personally, most of the time I'm more tolerant to trading off performance for battery juice, which isn't everyone wants, so it's not really reflected in the stock parameters. Sure, in terms of raw performance/battery ratio, my preferences would probably be lower, but in terms of utility, it's a whole different story.
Do whatever you want. I really couldn't care less. I gave you advice when you asked. It is clear you lack experience yet think you're clever enough to mess with cpu frequencies and in the end you will gain absolutely nothing. so have at it. I've seen many inexperienced people cry for help when they fry their phones from doing things they think they understand.