Related
I ask because different roms and kernels offer different benefits. Some allow you to overclock. Some allow you to get high Mflops running Linpack.
Mflops is a measure of how fast calculations are being performed (forgive my butchered definition). Mhz is how fast info is being processed. Which is king?
For example, I can underclock my processor to save battery life, but am using a ROM that generates high Mflops in Linpack. OR, I could overclock my processor for performance on a ROM that does not generate high Mflops.
Which would be faster?
My next question is: Do Mflops really matter? From Wikipedia:
"...a hand-held calculator must perform relatively few FLOPS. Each calculation request, such as to add or subtract two numbers, requires only a single operation, so there is rarely any need for its response time to exceed what the operator can physically use. A computer response time below 0.1 second in a calculation context is usually perceived as instantaneous by a human operator,[2] so a simple calculator needs only about 10 FLOPS to be considered functional."
Click to expand...
Click to collapse
If once a certain Mflop is reached the calculation seems "instantaneous," then who cares if they are higher than instantaneous? Will we ever really "perceive" the benefit of 50Mflops on our phones?
Anybody that can shed some light on this for me? It would be much appreciated!
For every-day use, you will notice a much larger impact with the higher clock speed.
TheBiles said:
For every-day use, you will notice a much larger impact with the higher clock speed.
Click to expand...
Click to collapse
What other use is there? Do you mean that processor speed is more important for speeding up the UI?
I would like to see an intelligent answer to this question with data or at least a solid theory to support it.
i may not be able to provide you with an engineers answer
but imma say... the one that sucks up less battery and provides fast calculations is the winner. so a 500mhz proc running higher flops would be my best decision
heck, i dunno.
That increase in mflops is from jit compiling java apps. The core os and browser are already native as are 3d games. They might speed up some from less java overhead.
MHz is not a measurement of "how fast info is processed", it is the clock speed of the processor. All it signifies is the rate at which the processor performs its operations. 1,000 MHz means the CPU has 1,000,000,000 cycles per second. Some operations will take one cycle to perform, other operations will take several cycles. Most software, unless it is exceptionally well written (in assembly language, which I don't believe can be executed on android) will require millions of CPU operations to perform whatever task it is trying to perform.
Increasing your clock speed while keeping all other things equal will increase all of your computing power and should give a useful gain in performance.
Linpack measures numeric floating point calculations. This is one of many types of tasks that a CPU must perform. Linpack is not an overall measurement of system performance, it's a measure of pure numeric (floating point) processing power. I have no idea how some roms manage to improve Linpack that dramatically, and you'd need to know that in order to truely answer your question. It seems likely to me that it's just a floating point optimization method that gives the higher scores, in this case floating point operations are the only things that would be improved.
The simple answer is that it depends what you want to do with your phone. If you do something with a lot of floating point calculation (3d games are an example, but they would typically use 3d hardware acceleration rather than cpu power, I'm not sure exactly how the snapdragon is designed so I'm not sure that they are not one and the same), you would get more performance out of the system with the higher linpack score. The higher clock speed on the other hand would provide you more overall benefit, it would make everything faster instead of just one area.
mhz doesn't necessarily mean speed. It's a easy, barely valid way to compare speeds to like model and generation processors only.
Platform independent benchmarks are much more important and reliable for judging speed. Therefore, a 500mhz processor that performs 20mflops is faster (at least in floating point operations) than a 1000mhz processor that performs 10 mflops.
Also realize, floating point operations per second are only one small part of a computer's performance. There's Specviewperf for Graphics performance, for instance, or general performance benchmarks like the whetstone or dhrystone.
Lets me see if I can shed some light:
In a basic processor you have 4 general tasks performed: Fetching, Decoding, Execution, and Writeback.
Processor clock rate (despite what people think) is not indicative of speed. It is an indicator of the number of wave cycles per second. Depending on the amount of work per cycle that a processor can do, then determines the "speed" of a processor. For instance an Intel 3ghz processor may be able to execute 100 integer calculations per cycle for a total of 300 billion calculations per second; but an AMD 3ghz processor could be able to do 200 integer calculations per second effectively making it the more efficient and "faster" processor.
A perfect example of this is the Hummingbird vs Snapdragon debate. Two processors at the same speed, yet Samsung claims the Hummingbird is faster due to the higher amount of work per cycle that can be executed.
The next step in the chain then comes when determining the types of calculations performed. An AMD processor may work better with a customized Linux based system that uses a higher level of floating point calculations, while an Intel processor may be better suited to a Windows system that uses a high level non-floating integers.
The next question is this: does your phone, a Linux based system use a high enough level Floating Point operations to make a difference in overall performance?
Google apparently does. However, Floating Point operations are simply a generic benchmark of a single facet of the operating system as a whole. Less wave cycles per second will decrease the overall potential of work, thereby decreasing performance in cases where the work needed to be executed exceeds the number of available waves.
Therefore, I would vote for the higher processor speeds, unless the only programs you execute use Floating Points.
Scientific enough?
Feel free to PM me with questions, or post here...
There are other factors that greatly affect processors as well, such as latency, BUS speed, and RAM available for buffering, but I didn't want to do an information overload.
~Jasecloud4
Sorry, I was assuming we were talking about the same processor (namely, the EVO's) clocked at two different speeds. It would make sense that the slower clock speed vielded more Mflops if it had JIT enabled, but I still think you would find the UI snappier with a higher-clocked ROM without JIT.
I notice a greater speed improvement from jit more than a faster processor speed. Especially with apps that have to load your whole system like autostarts. Battery life however, I'm still learning about. With Damage and being OC'd battery life was great. I'm currently on the latest CM nightly with jit and setcpu. We'll see how that compares.
Sent from my EVO using xda App
Quick off-topic question, then we'll get back on topic. Does the CyanogenMod build have the FPS broken?
TheBiles said:
Sorry, I was assuming we were talking about the same processor (namely, the EVO's) clocked at two different speeds. It would make sense that the slower clock speed vielded more Mflops if it had JIT enabled, but I still think you would find the UI snappier with a higher-clocked ROM without JIT.
Click to expand...
Click to collapse
lol you say that as if you dont actually know it...
deep inside we both know it though...
but seriously, both of biles' post on P1 sum up the question from the OP. Trust us
Tilde88 said:
lol you say that as if you dont actually know it...
deep inside we both know it though...
but seriously, both of biles' post on P1 sum up the question from the OP. Trust us
Click to expand...
Click to collapse
I'm a computer engineer, so I at least like to assume that I know what I'm talking about...
This thread is comparing Apples to Oranges. If the number of waves per second on a processor is increased, then the number of floating point calculations will increase, if every other factor remains the same.
It stands to reason that when two systems, one at 500MC/psec is pitted against another at 1000MC/psec with both systems running the same OS and JIT enabled, the one running at 1000MC/psec will have a higher number of floating points calculated.
~Jasecloud4
jasecloud4 said:
This thread is comparing Apples to Oranges. If the number of waves per second on a processor is increased, then the number of floating point calculations will increase, if every other factor remains the same.
It stands to reason that when two systems, one at 500MC/psec is pitted against another at 1000MC/psec with both systems running the same OS and JIT enabled, the one running at 1000MC/psec will have a higher number of floating points calculated.
~Jasecloud4
Click to expand...
Click to collapse
True, but I don't think we're talking about identical ROMS, since different ROMS have different abilities to OC and/or run JIT.
dglowe343 said:
I notice a greater speed improvement from jit more than a faster processor speed. Especially with apps that have to load your whole system like autostarts.
Click to expand...
Click to collapse
Running the nightly CM Froyo ROM right now and Autostarts is also the only app I have perceived to have a significant speed improvement from JIT. It really is the 2-5x faster that Google claimed JIT would be, but I've yet to see any other apps that benefit as much as Autostarts. Everything else seems the same as a non-JIT 2.1 ROM.
Haven't tried any games since getting the phone though, so can't give any feedback on those.
I think another poster in the CM Nightly rom thread compared his browser to his brothers 2.1 ROM phone, and the browsers were just about the same speed wise as well.
Given that feedback, I'd say for general usage a higher clock speed is better than lower clock speed and higher Mflops.
How has this thread gotten so long without the word "frequency" mentioned once? You guys are making this way too difficult. In 1 GHz, the Hz is the unit for frequency, which just means cycles per second. If you want a simple analogy, imagine a hamster running. His legs are moving up and down and forward at a certain frequency. You're running, too. Let's say that you are running at the same frequency. Who is getting somewhere quicker? Obviously you are because your legs are longer and stronger and you have a better power to weight ratio. Processors can behave the same way. Some simply get more done than others when operating at the same frequency for various reasons. This is why looking at only frequency is useless. Instead, we look at the work that it can do. Flops (floating point operations per second) is one measure of the work that a processor can do. There are many other ways to measure performance. This is just one of them.
Why do we want faster processors? It is partially so that we can be faster, but mostly so that we can do more. If you were to run the OS from phones 10 years ago on the hardware of today, most operations would be essentially instantaneous and with smart power saving features, you wouldn't need to charge it but once a week or less. But today's phones do far more. We need those higher speeds because even when you're sitting there looking at the home screen and "not doing anything", the OS is running dozens of services in the background to keep everything working correctly. Imagine if we were to take a modern engine and put it in an econo car from 30 years ago. It would go like hell and be incredibly efficient but it wouldn't have the safety, comfort, or features that we've come to expect with a modern automobile.
Sprockethead said:
Quick off-topic question, then we'll get back on topic. Does the CyanogenMod build have the FPS broken?
Click to expand...
Click to collapse
Yes. I avg 50-55 fps.
Sent from my EVO using xda App
jasecloud4 said:
This thread is comparing Apples to Oranges. If the number of waves per second on a processor is increased, then the number of floating point calculations will increase, if every other factor remains the same.
It stands to reason that when two systems, one at 500MC/psec is pitted against another at 1000MC/psec with both systems running the same OS and JIT enabled, the one running at 1000MC/psec will have a higher number of floating points calculated.
~Jasecloud4
Click to expand...
Click to collapse
um yea, but have you ever OC a video card for example?
lets take my old nVidia 8800gtx...
just because I overclock my core speeds doesnt mean that my memory bus will also be up'd, (of course the option is there but for the sake of the thread we'll ignore that)
Sure, now itll be able to process things much faster, but it cannot render as quickly as its ciphering, buffering, processing... etc...
like biles said, up the CPU for snappier user interfacing, up the flops for lets say, vb compiling ...
im not at my most sober points right now, so if you cant comprehend what im saying, think of the 'core' speed as the CPU, and the 'bus' speed as mFLOPS ...
and well gaming and rendering effects can see an improvement through JIT, but only if the said app or whatnot was built with JIT. otherwise it would be like upscaling a standard DVD to 720p. and seeing as how 3d rendering is after all native, how much more gfx tweaks do we need?
I just scored 2597 on a DK17 FroYo ROM (Quantum Rom v1.5 {WarpSpeed}) running at a stock 1.0 GHz. I believe this sets a record for a stock CPU on Android.
(At least it does according to smartphonebenchmarks.com) UPDATE - It's official. This is the 8th highest recorded Quadrant score and the very highest recorded stock clocked CPU score on that website.
This score was made possible by the EXT3 (EDIT - Correction, ramdisk) hack implemented in the most recent version of the ROM, released this morning.
EDIT - I'd like to note that the "lagfix" was incorporated into the ROM by the author with noobnl's assistance to prove a point; neither condone the serious use of Quadrant scores in it's current form. This hack is purely a Quadrant scores boost and does not provide real-world benefits. It is a demonstration that we should not rely upon inaccurate measurements to tell us what ROM or hardware is best.
An exploitable benchmark is no benchmark at all.
http://dl.dropbox.com/u/11825908/snap20101127_124836.png
http://dl.dropbox.com/u/11825908/snap20101127_131805.png
So just to clarify, does the ext3 hack do nothing other than improve benchmark scores? Is there any real-world improvement?
As common knowledge as the Quadrant thing is, I'm amazed people KEEP IMPLEMENTING this tweak and bragging about the results... unless there was an actual (less-drastic than Quadrant shows) improvement.
I agree that first we have to look at the big picture..while it may not help as much as the number makes it out to be, that doesn't necessary mean that it gives no benefit.
Next is this, why do people complain about Quadrant so much? you are using a FREE version..the FREE version only gives you a total number..Quadrant Pro on the other hand gives you the scores in each category..and is actually one of the best for measuring atm on android...
Electrofreak said:
I just scored 2597 on a DK17 FroYo ROM (Quantum Rom v1.5 {WarpSpeed}) running at a stock 1.0 GHz. I believe this sets a record for a stock CPU on Android.
(At least it does according to smartphonebenchmarks.com)
This score was made possible by the EXT3 hack implemented in the most recent version of the ROM, released this morning.
An exploitable benchmark is no benchmark at all.
http://dl.dropbox.com/u/11825908/snap20101127_124836.png
http://dl.dropbox.com/u/11825908/snap20101127_131805.png
Click to expand...
Click to collapse
it is true, we mounted benchmark data folder as a ramdisk/tmpfs, theres no ext3 filesystem in the rom because just for the lulz and educate the group that a lag fix won't do ****.. just to cheat a benchmark.. we were pissed at roms user thinking making rfs to ext3 will make performance better...
gTen said:
I agree that first we have to look at the big picture..while it may not help as much as the number makes it out to be, that doesn't necessary mean that it gives no benefit.
Next is this, why do people complain about Quadrant so much? you are using a FREE version..the FREE version only gives you a total number..Quadrant Pro on the other hand gives you the scores in each category..and is actually one of the best for measuring atm on android...
Click to expand...
Click to collapse
It has nothing to do with cost. It has to do with the fact that Quadrant is the most commonly used benchmark and it is deeply flawed.
Yes, the Pro version does break down the scores. Most people don't pay for Quadrant. Secondly, the I/O scores are weighted very heavily... the score nearly tripled because an I/O test completed a little quicker. There's a significant problem with that.
I've been impressed by the Epic's speed, but your scores aren't truly valid because you are "cheating"
I assume you're using the new Quantum ROM (which I also have installed) that implements a lagfix in which one moves the app data and dalvik cache away from Samsung’s embarrasingly slow internal Storage. Doing this significantly boosts I/O scores in Quadrant, thereby cheating the system. In real-life use, your system is barely performing any faster than before the exploit/lagfix
Read here for more info to see how a dev exploited this to create a 3300 Quad score (can't post links so remove the spaces):
http : // androidspin .com /2010/08/23/my-quadrant-is-bigger-than-your-quadrant/
This exploit has even been confirmed by the almighty Cyanogen himself
So is there any real benifits to this Epic 4G "lag fix"? I've seen that the "lag fix" within the other galaxy S phones actually does give real world results...
Eazail70x7 said:
So is there any real benifits to this Epic 4G "lag fix"? I've seen that the "lag fix" within the other galaxy S phones actually does give real world results...
Click to expand...
Click to collapse
Sure, it provides a speed benefit. The only thing being addressed in this thread is that, just because your quadrant scores double, it doesn't mean your device is twice as fast in actual use
Look for Dameon's post a couple of days ago in the quantum rom thread (on tapatalk..and linking sux). He talks about this exploit, but sadly (and understandably), most of the rom migrants want something to quantify expected results.. Even if bs
sent from my RAZR
Its not fair to say quadrant cheats.. rather it just may or may not be measuring performance of an operation that is ever really used on your system. In fact your system does use some fsyncs like quadrant and those will be faster like quadrant. Your system could start using fewer fsyncs though and quadrant would never know. Also your device certainly doesn't use only fsyncs..but those are very related to the lag. So basically, quadrant says the lag fix works if I'm not missing something. That's OK...but you don't need a crazy number to say that.
Bottom line... the only thing that tells how your phone performs...is how your phone performs and that's not just some little disclaimer. Hardware speed depends DRAMATICALLY on how it is used.
Sent from my SHW-M110S using XDA App
biff6789 said:
Sure, it provides a speed benefit. The only thing being addressed in this thread is that, just because your quadrant scores double, it doesn't mean your device is twice as fast in actual use
Click to expand...
Click to collapse
Actually the tweak, as noobnl states, quite specifically provides NO performance improvements to the phone. He would know because he made the hack. See the quote below.
noobnl said:
it is true, we mounted benchmark data folder as a ramdisk/tmpfs, theres no ext3 filesystem in the rom because just for the lulz and educate the group that a lag fix won't do ****.. just to cheat a benchmark.. we were pissed at roms user thinking making rfs to ext3 will make performance better...
Click to expand...
Click to collapse
Moving on...
biff6789 said:
I've been impressed by the Epic's speed, but your scores aren't truly valid because you are "cheating"
I assume you're using the new Quantum ROM (which I also have installed) that implements a lagfix in which one moves the app data and dalvik cache away from Samsung’s embarrasingly slow internal Storage. Doing this significantly boosts I/O scores in Quadrant, thereby cheating the system. In real-life use, your system is barely performing any faster than before the exploit/lagfix
Read here for more info to see how a dev exploited this to create a 3300 Quad score (can't post links so remove the spaces):
http : // androidspin .com /2010/08/23/my-quadrant-is-bigger-than-your-quadrant/
This exploit has even been confirmed by the almighty Cyanogen himself
Click to expand...
Click to collapse
This was the whole point of my post... I think you might have missed that. I would also recommend this article as well: http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws
Electrofreak said:
It has nothing to do with cost. It has to do with the fact that Quadrant is the most commonly used benchmark and it is deeply flawed.
Yes, the Pro version does break down the scores. Most people don't pay for Quadrant. Secondly, the I/O scores are weighted very heavily... the score nearly tripled because an I/O test completed a little quicker. There's a significant problem with that.
Click to expand...
Click to collapse
Well realistically speaking even without the I/O exploit the none pro version never had any meaning to it..why?
Well it measures:
CPU
Memory
I/O
2d
3d
Now lets look at it from perspective..lets say we have a score of 3000 and 99% of it comes from 3d..the phone would still be laggy because even though it may have a good gpu it won't have the other things to back it up.
Quadrant weighs everything evenly...it exists for the sole purpose of getting people to buy the pro version..
So its not Quadrant that is flawed but the people who actually think a large number means everything is automatically super fast...
So in most cases yes, the I/O increase would be almost useless as nothing would utilize it to the point where you would need to utilize such high I/O..unless maybe you plan to run a database server on your phone? lol
But like any benchmark we have to not only look at the number but understand what the number means..similar to how on a linpack gets cheated on with use of a VFP since it measures with floating points...
Heck I can write a program called gTen Score which does an md5 sum of every file on the device and the closer the device is to mine the higher score it would get..would that make the device with the highest score the best? lol..benchmarks are benchmarks...we have to understand them and look at the details to how the numbers got there..In my opinion if its not Quadrant Pro people are wasting their time with the benchmark...
gTen said:
Well realistically speaking even without the I/O exploit the none pro version never had any meaning to it..why?
Well it measures:
CPU
Memory
I/O
2d
3d
Now lets look at it from perspective..lets say we have a score of 3000 and 99% of it comes from 3d..the phone would still be laggy because even though it may have a good gpu it won't have the other things to back it up.
Quadrant weighs everything evenly...it exists for the sole purpose of getting people to buy the pro version..
So its not Quadrant that is flawed but the people who actually think a large number means everything is automatically super fast...
So in most cases yes, the I/O increase would be almost useless as nothing would utilize it to the point where you would need to utilize such high I/O..unless maybe you plan to run a database server on your phone? lol
But like any benchmark we have to not only look at the number but understand what the number means..similar to how on a linpack gets cheated on with use of a VFP since it measures with floating points...
Heck I can write a program called gTen Score which does an md5 sum of every file on the device and the closer the device is to mine the higher score it would get..would that make the device with the highest score the best? lol..benchmarks are benchmarks...we have to understand them and look at the details to how the numbers got there..In my opinion if its not Quadrant Pro people are wasting their time with the benchmark...
Click to expand...
Click to collapse
You make some very good points, but Quadrant IS flawed in that it should be able to test performance in a manner that is more consistent with real-world performance. A benchmark tool that provides poor results for a different configuration of hardware or software (in this case, Samsung's RFS file system) when performance is in on par or even superior to a higher-scoring configuration is a benchmark tool with serious flaws.
Electrofreak said:
You make some very good points, but Quadrant IS flawed in that it should be able to test performance in a manner that is more consistent with real-world performance. A benchmark tool that provides poor results for a different configuration of hardware or software (in this case, Samsung's RFS file system) when performance is in on par or even superior to a higher-scoring configuration is a benchmark tool with serious flaws.
Click to expand...
Click to collapse
The flaw of quadrant is grouping up all of those categories into 1...usually as you said things are weighted into a benchmark and each benchmark measures things like 3d performance, i/o performance an etc would each be a separate benchmark..Quadrant will never do that because their goal is for you to buy the pro version...it was never intended to be used for anything other then a proof of concept for selling the pro version...
Since people are not gonna buy Quadrant Pro..the best way is to get them to use a different benchmark...I hear some people touting GLBenchmark is it any better?
gTen said:
The flaw of quadrant is grouping up all of those categories into 1...usually as you said things are weighted into a benchmark and each benchmark measures things like 3d performance, i/o performance an etc would each be a separate benchmark..Quadrant will never do that because their goal is for you to buy the pro version...it was never intended to be used for anything other then a proof of concept for selling the pro version...
Since people are not gonna buy Quadrant Pro..the best way is to get them to use a different benchmark...I hear some people touting GLBenchmark is it any better?
Click to expand...
Click to collapse
I've been following GLBenchmark and it seems pretty accurate as far as I can tell. A buddy of mine outed the HTC Glacier (Mytouch 4G) when he found that a developer had erroneously left scores posted on GLBenchmark.com. We could tell it was a next-gen Snapdragon by the scores, and that it wasn't running an Adreno 200. Became big news soon thereafter.
Electrofreak said:
I've been following GLBenchmark and it seems pretty accurate as far as I can tell. A buddy of mine outed the HTC Glacier (Mytouch 4G) when he found that a developer had erroneously left scores posted on GLBenchmark.com. We could tell it was a next-gen Snapdragon by the scores... became big news soon thereafter.
Click to expand...
Click to collapse
Well then the best bet is to contact rom developers and ask if they could include GLBenchmark instead of quadrant and explain the benefits of having a specified benchmark over a general unweighed one..
and yeah I saw th HTC Glacier thing..
Electrofreak said:
This was the whole point of my post... I think you might have missed that. I would also recommend this article as well: http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws
Click to expand...
Click to collapse
You're right, I originally DID miss your point. My bad... I thought you were just another fanboi raving about the awesomeness of Quadrant. I should have read more carefully
But in essence, you and I were saying the same thing all along: Quadrant is bunk and can easily be manipulated by a tmpfs tweak
As for my other point about lagfixes offering real-world performance boosts in other phones, I was saying "yes" in a general way as often times they do, not "yes" specifically regarding Dameon's tweak
biff6789 said:
You're right, I originally DID miss your point. My bad... I thought you were just another fanboi raving about the awesomeness of Quadrant. I should have read more carefully
But in essence, you and I were saying the same thing all along: Quadrant is bunk and can easily be manipulated by a tmpfs tweak
As for my other point about lagfixes offering real-world performance boosts in other phones, I was saying "yes" in a general way as often times they do, not "yes" specifically regarding Dameon's tweak
Click to expand...
Click to collapse
Yeah, and from what I understand (forgive me, I am still a relative newcomer here) the other Galaxy S phones mount their file directory a little differently than the Epic does, negating the need for a real lag fix. However, the Captivate lag-fix, for example, does indeed provide actual performance improvements. Perhaps this misunderstanding is what is causing people to believe that the Epic needs to have some sort of lag fix too.
Electrofreak said:
Yeah, and from what I understand (forgive me, I am still a relative newcomer here) the other Galaxy S phones mount their file directory a little differently than the Epic does, negating the need for a real lag fix. However, the Captivate lag-fix, for example, does indeed provide actual performance improvements. Perhaps this misunderstanding is what is causing people to believe that the Epic needs to have some sort of lag fix too.
Click to expand...
Click to collapse
You're exactly right. Dameon himself stated that the other Galaxy phones need a lagfix while the Epic does not (read the last line of the following post):
http://forum.xda-developers.com/showpost.php?p=9440522&postcount=1174
quadrant has been known to very inaccurate. I forget who it was but someone tweaking their evo was able to get like 6000 on quadrant awhile ago. After that it has been tricked many times into giving big numbers with no actual improvements over the actual phone itself.
I had always read that CPU performance increases were logarithmic with respect to frequency, so I decided to do some testing myself and share the results, which do confirm this (I wasn't doubting it, but wanted to see some actual hands-on data, what can I say, I'm a science student). I thought the forum might be interested in seeing it.
System Info:
Ziggy471 BFS Kernel, 4.4.11 build
Das BAMF 1.3.2 ROM
Procedure:
At each frequency I tested, I did 3 SetCPU Long Benchmark tests and 3 Linpack tests. I know these are not necessarily representative of performance, but they do provide a nice numerical comparison. I averaged the 3 results for each frequency and plotted them. The SetCPU Benchmark shows an especially distinctive exponential decay curve, (Lower is better for SetCPU, higher is better on Linpack) but the Linpack one also displays a vaguely logarithmic shape, although not as distinctive as the SetCPU one.
Plots are attached.
Hopefully, this information will at least be found interesting by some of you who were not already aware of the logarithmic curve of performance and maybe even guide decisions on how high of a frequency is worth it. But obviously my results are not the gospel or anything, just the results I obtained for these tests.
I did some similar testing with roughly the same results. After 1.4ghz you typically get diminishing returns. Tested with several roms and several kernels all with same results. currently running perfect storm 1.2 with ziggy's kernel pre-loaded and is very fast...but let's be honest...the phone is plenty fast stock...we really need more battery!!!! lol
thanks for sharing.
Yeah, it seems across all benchmarks the gains really drop out past ~1.4-1.5.
..Coming from the Eris where I was extremely excited to see 5.1 mflops, well, nuff said I guess....
Luv this fone!!
Perfect Storm stock kernel (ziggy's) is set and 1408mhz...my phone benchmarks faster at 1382mhz so that's what i have settled on.
patdroid1 said:
I did some similar testing with roughly the same results. After 1.4ghz you typically get diminishing returns. Tested with several roms and several kernels all with same results. currently running perfect storm 1.2 with ziggy's kernel pre-loaded and is very fast...but let's be honest...the phone is plenty fast stock...we really need more battery!!!! lol
thanks for sharing.
Click to expand...
Click to collapse
Yup. I'm done with the quad wars. I really hope we get better battery life fast.... Also, I noticed the same diminishing returns as well.
Sent from my thunderbolt
Its to the point where speed is a non issue. I'm not running matlab on this phone, I'm playing pokemon. I'm happy with how fast it is, now if i could get my battery up from 12 hours to ~ 18 I would **** bricks.
athorax said:
Its to the point where speed is a non issue. I'm not running matlab on this phone, I'm playing pokemon. I'm happy with how fast it is, now if i could get my battery up from 12 hours to ~ 18 I would **** bricks.
Click to expand...
Click to collapse
Hahaha. You echoed my sentiments precisely.
Sent from my thunderbolt
We might not be seeing diminishing returns.. what if Linpack isn't properly generating a end result because the phone begins to be too fast for it?
We need much longer tests to get more accurate results.
Diversion said:
We might not be seeing diminishing returns.. what if Linpack isn't properly generating a end result because the phone begins to be too fast for it?
We need much longer tests to get more accurate results.
Click to expand...
Click to collapse
do smartbench
It's nice to know that I"m not the only one nerdy enough to do this. I saw similar results.
Nbench will be good for that, it is very accurate and it takes about 10min to complete, its a stability test rolled into one. Its the only way I can accurately gauge my xoom dual core. OOOO, thunderbolt vs xoom in nbench, give me 10 min...
XOOM
Memory 2.86
Integer 3.89
Float 1.17
Thunderbolt 2.0 kernel, no OC
Memory 2.73
Integer 4.07
Float 0.94
surprising results, thought the xoom would be better, must not be fully implementing dual core in 3.0
Based on the graph, looks like all real gains are minimal for the risk above the chips 1.4ghz rating. Good to know that its almost useless to really OC, and just unlock it to the rated frequency.
This is interesting, I'll have to do a little testing myself. Thanks.
I only used results on which Linpack claimed to have a highly accurate result, but it's probably possible that it's not accurate at the higher clock speeds. I kind of doubt it though. The reason I used quicker tests (Linpack & SetCPU) is because I figured it would be a good enough statistic to compare performance of different clock speeds but on the same ROM and kernel, while allowing me to do multiple trials of each clock rate without the "experiment" being overly time-consuming.
The sticking point for me on chalking it up to inaccuracy is the fact that if you fit a logarithmic function to the SetCPU plot, the R² value is .9947, meaning it's almost a perfect fit.
Additionally, I think you start getting more errors and near kernel panics, as I believe they're referred to in *nix systems, at the higher clock rates (1.7, 1.8, etc) where the voltage, in this particular case, cannot be safely increased but isn't sufficient for that rate. Most of what I know about this is just from my experience in undervolting Macs, though. I'm far from an expert.
dacre said:
I only used results on which Linpack claimed to have a highly accurate result, but it's probably possible that it's not accurate at the higher clock speeds. I kind of doubt it though. The reason I used quicker tests (Linpack & SetCPU) is because I figured it would be a good enough statistic to compare performance of different clock speeds but on the same ROM and kernel, while allowing me to do multiple trials of each clock rate without the "experiment" being overly time-consuming.
The sticking point for me on chalking it up to inaccuracy is the fact that if you fit a logarithmic function to the SetCPU plot, the R² value is .9947, meaning it's almost a perfect fit.
Additionally, I think you start getting more errors and near kernel panics, as I believe they're referred to in *nix systems, at the higher clock rates (1.7, 1.8, etc) where the voltage, in this particular case, cannot be safely increased but isn't sufficient for that rate. Most of what I know about this is just from my experience in undervolting Macs, though. I'm far from an expert.
Click to expand...
Click to collapse
Holy crap! Im sure glad there are guys/gals like the ones in this thread to figure this stuff out because I feel like I walked into Trig class all over again. BTW I hated that stuff but in my own dumba$$ speak, this is kinda what I though. What I mean to say is this is a mobile, comparably lowres, linux based system, so how much speed is enough? One would think that at 1.5-1.8 it would be getting "maxed". If not "maxed" then at least enough that 90% of all users would be so thrilled and never see a need for more, that it would be fine. I (like so many others w TB's) would love to see a way to make that battery last just one full day with average usage. Thanks for all the effort you guys are putting in this! Look fwd to great ROMs as the dev work progresses.
Just using the phone, the higher frequencies actually can feel slower. Am I the only one that noticed? I run 1.4 gHz on the LeanKernel 1.9. Did anyone else realize you can bring it to 1.9? It gets really hot, really fast though.
Nope, mine is the same way. My phone is much snappier at ~1.4-1.5GHz than at 1.6GHz+.
I believe this is because the CPU starts derping up when it's at a clock speed higher than it can handle well (which varies from chip to chip); I think eventually when a big enough error happens it results in a kernel panic (where the phone freezes and eventually reboots), but I'm not exactly sure on how it works.
A quick note on the theoretics from someone who studied embedded systems...
Theoretically performance gain should be proportional to CPU frequency (double your frequency, halve your processing time). In practice you often see what you are seeing here, which is the effect of another system on the phone being the performance bottleneck. Without knowing anything about the cpu architecture and exactly how linpack is designed, it's hard to judge where that bottleneck is on the TB, but the point is that performance should be linear with cpu frequency.
Instead of averaging over 3 trials it would probably be better to take the *best* out of, say, 10 trials.
I'm assuming it's somewhat the same as testing runtime of particular algorithms on a computer--you want the best result you get because it actually is the closest to the actual answer. Processors won't "glitch" to being faster than they really are, so a slower result just means that some of the processor was used for something else (another background program perhaps). You will never get all of the processor's "attention" when doing tests like these on your own phone, so go with the result you get when you get *most* of the processor's attention!
Just a thought
Looking good, battery ok, feels smooth.
2.3.4 Quadrant
At last 2.3.4 seems to be very fast ! Quadrant score with out ext4 is 1600-1800 amazing!
PDA:XXJVP
MODEM:XXJVO
CSC:JV4XEN
Why are you all using Quadrant?
Run it 3 times and you won't even get the same score :| Pretty not reliant as a benchmark!
you won`t get same score cuz first time i like a cold start , it loades files etc.. second time you will get a better score
When you run 3dmark on a PC, you get the same (or around the same) score, same goes to a lot of benchmark software out there. Caching a benchmark goes against benchmarking itself...
t1mman said:
When you run 3dmark on a PC, you get the same (or around the same) score, same goes to a lot of benchmark software out there. Caching a benchmark goes against benchmarking itself...
Click to expand...
Click to collapse
Even that probably isn't truly indicative of performance. Nvidia and ATI both "optimise" *cough cheat* on benchmarks. Nvidia may blitz ATI in a certain game, but another game might be optimised for ATI. 3D mark also doesn't go into enough detail about what its testing (similar to Quadrant), which makes them both toys, because you don't get a breakdown. It doesn't tell you even basic stuff such as average random I/O speeds and very few benchmarks ensure that the test is run in a consistent fashion. You running the same test a second time leads to significantly better results, then caching is taking place, and the effect of caching should be added to the results too.
Benchmarks have unfortunately grown from an optimisation tool for developers, to a marketing tool for salespeople, and endusers who wish to boast. My suggestion, is that you should ignore them, and if you think the ROM feels nice, just use it. But, it seems most people are simply deciding on whether a ROM is nice AFTER they've seen the quadrant score, and that is a step backwards.
Its entirely possible to have dreadful real-world performance, but have the worlds highest Quadrant result (just like in a car, you might be able to drive 90km with 1litre of petrol. But if you only obtain that rate at 1km/h, its useless to almost everyone, especially if at 50km/h (normal speed), it starts gulping fuel like a ferrari).
Do you?
Do you keep it overckocked for a longer period, permanently, or just when/while you need it? How much (exact frequencies would be cool) I'm thinking of OCing mine (both CPU and GPU) since some games like NOVA 3 lag on occasions but not sure how safe/advisable it is.
Sent from my Nexus 7 using Tapatalk HD
I don't think it's needed. I've heard that OC won't help much with gaming, but you can definitely try
I don't yet - I might later. My N7 is still less than a month old.
The device manufacturers (e.g. Asus in this case) have motivations to "not leave anything on the table" when it comes to performance. So, you have to ask yourself - why would they purposely configure things to go slowly?
After all, they need to compete with other handset/tablet manufacturers, who are each in turn free to go out and buy the exact same Tegra SoC (processor) from Nvidia.
At the same time, they know that they will manufacture millions of units, and they want to hold down their product outgoing defect levels and in-the-field product reliability problems to an acceptable level. If they don't keep malfunctions and product infant mortality down to a fraction of a percent, they will suffer huge brand name erosion problems. And that will affect not only sales of the current product, but future products too.
That means that they have to choose a conservative set of operating points which will work for 99+ % of all customer units manufactured across all temperature, voltage, and clock speed ranges. (BTW, Note that Asus didn't write the kernel EDP & thermal protection code - Nvidia did; that suggests that all the device manufacturers take their operating envelope from Nvidia; they really don't even want to know where Nvidia got their numbers)
Some folks take this to mean that the vast majority of units sold can operate safely at higher speeds, higher temperatures, or lower voltages, given that the "as shipped" configuration will allow "weak" or "slow" units to operate correctly.
But look, it's not as if amateurs - hacking kernels in their spare time - have better informed opinions or data about what will work or won't work well across all units. Simply put, they don't know what the statistical test properties of processors coming from the foundry are - and certainly can't tell you what the results will be for an individual unit. They are usually smart folks - but operating completely in the dark in regards to those matters.
About the only thing which can be said in a general way is that as you progressively increase the clock speed, or progressively weaken the thermal regulation, or progressively decrease the cpu core voltage stepping, your chances of having a problem with any given unit (yours) increase. A "problem" might be (1) logic errors which lead to immediate system crashes or hangs, (2) logic errors (in data paths) that lead to data corruption without a crash or (3) permanent hardware failure (usually because of thermal excursions).
Is that "safe"?
Depends on your definition of "safe". If you only use the device for entertainment purposes, "safe" might mean "the hardware won't burn up in the next 2-3 years". Look over in any of the kernel threads - you'll see folks who are not too alarmed about their device freezing or spontaneously rebooting. (They don't like it, but it doesn't stop them from flashing dev kernels).
If you are using the device for work or professional purposes - for instance generating or editing work product - then "safe" might mean "my files on the device or files transiting to and from the cloud won't get corrupted", or "I don't want a spontaneous kernel crash of the device to cascade into a bricked device and unrecoverable files". For this person, the risks are quite a bit higher.
No doubt some tool will come in here and say "I've been overclocking to X Ghz for months now without a problem!" - as if that were somehow a proof of how somebody else's device will behave. It may well be completely true - but a demonstration on a single device says absolutely nothing about how someone else's device will behave. Even Nvidia can't do that.
There's a lot of pretty wild stuff going on in some of the dev kernels. The data that exists as a form of positive validation for these kernels is a handful of people saying "my device didn't crash". That's pretty far removed from the rigorous testing performed by Nvidia (98+% fault path coverage on statistically significant samples of devices over temperature, voltage, and frequency on multi-million dollar test equipment.)
good luck!
PS My phone has it's Fmax OC'ed by 40% from the factory value for more than 2 years. That's not a proof of anything really - just to point out that I'm not anti-OC'ing. Just trying to say - nobody can provide you any assurances that things will go swimmingly on your device at a given operating point. It's up to you to decide whether you should regard it as "risky".
Wow thanks for your educational response, I learned something. Great post! I will see if I will over clock it or not since I can play with no problems at all, it is just that it hics up when there is too much stuff around. Thanks again!
Sent from my Nexus 7 using Tapatalk HD
With the proper kernel its really not needed. Havent really seen any difference,aside from benchmark scores(which can be achieved without oc'ing)
Sent from my Nexus 7 using XDA Premium HD app
Yes, I run mine at 1.6 peak.
I've come to the Android world from the iOS world - the world of the iPhone, the iPad, etc.
One thing they're all brilliant at is responsive UI. The UI, when you tap it, responds. Android, prior to 4.1, didn't.
Android, with 4.1 and 4.2, does. Mostly.
You can still do better. I'm running an undervolted, overclocked M-Kernel, with TouchDemand governor, pushing to 2 G-cores on touch events.
It's nice and buttery, and renders complex PDF files far faster than stock when the cores peak at 1.6.
I can't run sustained at 1.6 under full load - it thermal throttles with 4 cores at 100% load. But I can get the peak performance for burst demands like page rendering, and I'm still quite efficient on battery.
There's no downside to running at higher frequencies as long as you're below stock voltages. Less heat, more performance.
If you start pushing the voltages past spec, yeah, you're likely into "shortening the lifespan." But if you can clock it up, and keep the voltages less than the stock kernel, there's really not much downside. And the upside is improved page rendering, improved PDF rendering, etc.
Gaming performance isn't boosted that much as most games aren't CPU bound. That said, I don't game. So... *shrug*.
Bitweasil said:
I can't run sustained at 1.6 under full load - it thermal throttles with 4 cores at 100% load.
Click to expand...
Click to collapse
@Bitweasil
Kinda curious about something (OP, allow me a slight thread-jack!).
in an adb shell, run this loop:
# cd /sys/kernel/debug/tegra_thermal
# while [ 1 ] ; do
> sleep 1
> cat temp_tj
> done
and then run your "full load".
What temperature rise and peak temperature do you see? Are you really hitting the 95C throttle, or are you using a kernel where that is altered?
I can generate (w/ a mutli-threaded native proggy, 6 threads running tight integer loops) only about a 25C rise, and since the "TJ" in mine idles around 40C, I get nowhere near the default throttle temp. But I am using a stock kernel, so it immediately backs off to 1.2 Ghz when multicore comes on line.
Same sort of thing with Antutu or OpenGL benchmark suites (the latter of which runs for 12 minutes) - I barely crack 60C with the stock kernel.
?
bftb0
The kernel I'm using throttles around 70C.
I can't hit that at 1200 or 1300 - just above that I can exceed the temps.
I certainly haven't seen 95C.
M-Kernel throttles down to 1400 above 70C, which will occasionally get above 70C at 1400, but not by much.
Bitweasil said:
The kernel I'm using throttles around 70C.
I can't hit that at 1200 or 1300 - just above that I can exceed the temps.
I certainly haven't seen 95C.
M-Kernel throttles down to 1400 above 70C, which will occasionally get above 70C at 1400, but not by much.
Click to expand...
Click to collapse
Thanks. Any particular workload that does this, or is the throttle pretty easy to hit with arbitrary long-running loads?
Odp: Do you overclock your N7?
I'll never OC a quadcore phone/tablet, I'm not stupid. This is enough for me.
Sent from my BMW E32 using XDA App
I've over clocked my phone, but not my N7. I've got a Galaxy Ace with a single core 800MHz processor OC'd to 900+. The N7 with its quad core 1.3GHz is more than enough for doing what I need it to do. Using franco.Kernel and everything is smooth and lag-free. No need for me to overclock
Sent From My Awesome AOSPA3.+/franco.Kernel Powered Nexus 7 With XDA Premium
Impossible to do so can't even get root but did manage to unlock the bootloader
Sent from my Nexus 7 using xda app-developers app
CuttyCZ said:
I don't think it's needed. I've heard that OC won't help much with gaming, but you can definitely try
Click to expand...
Click to collapse
I'm not a big OC'er, but I do see a difference in some games when I OC the GPU. It really depends on the game and what is the performance bottleneck. If the app is not Kernel bound than an OC won't make much difference. Must games are I/O and GPU bound.
Sent from my N7 using XDA Premium
Dirty AOKP 3.5 <&> m-kernel+ a34(t.10)
I've overclocked all of my devices since my first HTC hero. I really don't see a big deal with hardware life.
I know that this n7 runs games better at 1.6ghz than at 1.3ghz.
First thing I do when I get a new device is swap recovery and install aokp with the latest and greatest development kernel. Isn't that why all this great development exists? For us to make our devices better and faster? I think so. I'd recommend aokp and m-kernel to every nexus 7 owner. I wish more people would try non-stock.
scottx . said:
I've overclocked all of my devices since my first HTC hero. I really don't see a big deal with hardware life.
I know that this n7 runs games better at 1.6ghz than at 1.3ghz.
First thing I do when I get a new device is swap recovery and install aokp with the latest and greatest development kernel. Isn't that why all this great development exists? For us to make our devices better and faster? I think so. I'd recommend aokp and m-kernel to every nexus 7 owner. I wish more people would try non-stock.
Click to expand...
Click to collapse
Do you mean the pub builds of AOKP? Or Dirty AOKP
Ty
bftb0 said:
Thanks. Any particular workload that does this, or is the throttle pretty easy to hit with arbitrary long-running loads?
Click to expand...
Click to collapse
Stability Test will do it reliably. Other workloads don't tend to run long enough to trigger it that I've seen.
And why is a quadcore magically "not to be overclocked"? Single threaded performance is still a major bottleneck.
Bitweasil said:
Stability Test will do it reliably. Other workloads don't tend to run long enough to trigger it that I've seen.
And why is a quadcore magically "not to be overclocked"? Single threaded performance is still a major bottleneck.
Click to expand...
Click to collapse
Hi Bitweasil,
I fooled around a little more with my horrid little threaded cpu-blaster code. Combined simultaneously with something gpu-intensive such as the OpenGL ES benchmark (which runs for 10-12 minutes), I observed peak temps (Tj) of about 83C with the stock kernel. That's a ridiculous load, though. I can go back and repeat the test, but from 40C it probably takes several minutes to get there. No complaints about anything in the kernel logs other than the EDP down-clocking, but that happens just as soon as the second cpu comes on line, irrespective of temperature. With either of the CPU-only or GPU-only stressors, the highest I saw was a little over 70C. (But, I don't live in the tropics!)
To your question - I don't think there is much risk of immediate hardware damage, so long as bugs don't creep into throttling code, or kernel bugs don't cause a flaw that prevents the throttling or down-clocking code from being serviced while the device is running in a "performance" condition. And long-term reliability problems will be no worse if the cumulative temperature excursions of the device are not higher than what than what they would be using stock configurations.
The reason that core voltages are stepped up at higher clock rates (& more cores online) is to preserve both logic and timing closure margins across *all possible paths* in the processor. More cores running means that the power rails inside the SoC package are noisier - so logic levels are a bit more uncertain, and faster clocking means there is less time available per clock for logic levels to stabilize before data gets latched.
Well, Nvidia has reasons for setting their envelope the way they do - not because of device damage considerations, but because they expect to have a pretty small fraction of devices that will experience timing faults *anywhere along millions of logic paths* under all reasonable operating conditions. Reducing the margin, whether by undervolting at high frequencies, or increasing max frequencies, or allowing more cores to run at peak frequencies will certainly increase the fraction of devices that experience logic failures along at least one path (out of millions!). Whether or not OC'ing will work correctly on an individual device can not be predicted in advance; the only thing that Nvidia can estimate is a statistical quantity - about what percent of devices will experience logic faults under a given operating conditon.
Different users will have different tolerance for faults. A gamer might have very high tolerance for random reboots, lockups, file system corruption, et cetera. Different story if you are composing a long email to your boss under deadline and your unit suddenly turns upside down.
No doubt there (theoretically) exists an overclocking implementation where 50% of all devices would have a logic failure within (say) 1 day of operation. That kind of situation would be readily detected in a small number of forum reports. But what about if it were a 95%/5% situation? One out of twenty dudes report a problem, and it is dismissed with some crazy recommendation such as "have you tried re-flashing your ROM?". And fault probability accumulates with time, especially when the testing loads have very poor path coverage. 5% failure over one day will be higher over a 30 day period - potentially much higher.
That's the crux of the matter. Processor companies spend as much as 50% of their per-device engineering budgets on test development. In some cases they actually design & build a second companion processor (that rivals the complexity of the first!) whose only function is to act as a test engine for the processor that will be shipped. Achieving decent test coverage is a non-trivial problem, and it is generally attacked with extremely disciplined testing over temperature/voltage/frequency with statistically significant numbers of devices - using test-vector sets (& internal test generators) that are known to provide a high level of path coverage. The data that comes from random ad-hoc reports on forums from dudes running random applications in an undisciplined way on their OC'ed units is simply not comparable. (Even "stressor" apps have very poor path coverage).
But, as I said, different folks have different tolerance for risk. Random data corruption is acceptable if the unit in question has nothing on it of value.
I poked my head in the M-kernel thread the other day; I thought I saw a reference to "two units fried" (possibly even one belonging to the dev?). I assume you are following that thread ... did I misinterpret that?
cheers
I don't disagree.
But, I'd argue that the stock speeds/voltages/etc are designed for the 120% case - they're supposed to work for about 120% of shipped chips. In other words, regardless of conditions, the stock clocks/voltages need to be reliable, with a nice margin on top.
Statistically, most of the chips will be much better than this, and that's the headroom overclocking plays in.
I totally agree that you eventually will get some logic errors, somewhere, at some point. But there's a lot of headroom in most devices/chips before you get to that point.
My use cases are heavily bursty. I'll do complex PDF rendering on the CPU for a second or two, then it goes back to sleep while I read the page. For this type of use, I'm quite comfortable with having pushed clocks hard. For sustained gaming, I'd run it lower, though I don't really game.