Related
OK I've got mine on normal mode, and this kind of confirms my original thought that the 500mhz 5th core is clocked to low. I find the pad actually speeds up when I have multiple items in my recently run tab! If my understanding of the way it works these programs are still running in the background right? Then it starts kicking in the other 4 and not just running on the 5th at 500mhz! I really think we'd see a speed boost if we can get that 5th core over 500. Yes its supposed to save battery life but I really don't think 500 is fast enough to run on its own. You're thoughts and observations?
markimar said:
OK I've got mine on normal mode, and this kind of confirms my original thought that the 500mhz 5th core is clocked to low. I find the pad actually speeds up when I have multiple items in my recently run tab! If my understanding of the way it works these programs are still running in the background right? Then it starts kicking in the other 4 and not just running on the 5th at 500mhz! I really think we'd see a speed boost if we can get that 5th core over 500. Yes its supposed to save battery life but I really don't think 500 is fast enough to run on its own. You're thoughts and observations?
Click to expand...
Click to collapse
ill check on this when i get home. this issue im assuming is with honeycomb itself. we would assume that ICS would properly use those cores
Sent from my Samsung Galaxy S II t989
i don't have it yet (mine gets delivered on wed), but what you observed makes perfect sense. Can they change it to run on say an 800 MHZ constant "down" to 500MHZ when doing the most simple tasks? obviously i to do not believe that 500MHZ will be sufficient at all times to do screen scrolling and such on it's own.
I'm really hoping that the few performance issues people are seeing is resolved in firmware updates and a tegra 3 optimized version of ICS. Maybe asus/nvidia needs to do more tweaking to HC before the ICS build is pushed if it will take a while for ICS to arrive to the prime (past january).
The cores are optimized just fine. They kick in when rendering a web page or a game, but go idle and use the 5th core when done. Games always render.
ryan562 said:
ill check on this when i get home. this issue im assuming is with honeycomb itself. we would assume that ICS would properly use those cores
Sent from my Samsung Galaxy S II t989
Click to expand...
Click to collapse
Nothing's changed over HC in the way ICS uses h/w acceleration. And I'd assume apps using h/w acceleration do so via calls to the OS, not to the chip directly. So it appears what you've got is what you're going to get.
---------- Post added at 06:59 PM ---------- Previous post was at 06:55 PM ----------
markimar said:
OK I've got mine on normal mode, and this kind of confirms my original thought that the 500mhz 5th core is clocked to low. I find the pad actually speeds up when I have multiple items in my recently run tab! If my understanding of the way it works these programs are still running in the background right? Then it starts kicking in the other 4 and not just running on the 5th at 500mhz! I really think we'd see a speed boost if we can get that 5th core over 500. Yes its supposed to save battery life but I really don't think 500 is fast enough to run on its own. You're thoughts and observations?
Click to expand...
Click to collapse
Do you have Pulse installed? A bunch of people using it were reporting stuttering where their lower powered devices aren't. If you run it at full speed, does it stutter? One of the hypothesis is that it's the core's stepping up and down that's causing the stuttering.
BarryH_GEG said:
Nothing's changed over HC in the way ICS uses h/w acceleration. And I'd assume apps using h/w acceleration do so via calls to the OS, not to the chip directly. So it appears what you've got is what you're going to get.
Click to expand...
Click to collapse
Also, correct me if I'm wrong, but I don't think that the OS knows about the fifth core? I believe the chip's own scheduler manages the transition between the quad-core and the companion core, not the Android scheduler.
Mithent said:
Also, correct me if I'm wrong, but I don't think that the OS knows about the fifth core? I believe the chip's own scheduler manages the transition between the quad-core and the companion core, not the Android scheduler.
Click to expand...
Click to collapse
That's the way I'd guess it would work. I don't think Android addresses different chips differently. I'd assume it's up to the SoC to manage the incoming instructions and react accordingly. If Android was modified for dual-core, I don't think it diffentiates between the different implementations of dual-core chips. Someone with more h/w experience correct me if I'm wrong. Also, does anyone know if the chip manufacturer can add additional API's that developers can write to directly either instead of or in parallel with the OS? I ask because how can a game be optimized for Tegra if to the OS all chips are treated the same?
I tried out the power savings mode for a while.it seemed to perform just fine. Immediate difference is that it lowers the contrast ratio on display. This happens as soon as you press the power savings tab. Screen will look like brightness dropped a bit but if you look closely, you'll see it lowered the contrast ratio. Screen still looks good but not as sharp as in other 2 modes. UI still seems to preform just fine. Plus I think the modes doesn't affect gaming or video playback performance. I read that somewhere, either anandtech or Engadget. When watching vids or playing games, it goes into normal mode. So those things won't be affected no matter what power mode you in, I think..lol
I was thinking of starting a performance mode thread. To see different peoples results and thoughts on different power modes. I read some people post that they just use it in power/battery savings mode. Some keep it in normal all the time. Others in balanced mode. Would be good to see how these different modes perform in real life usage. From user perspective. I've noticed, so far, that In balanced mode, battery drains about 10% an hour. This is with nonstop use including gaming, watching vids, web surfing, etc. now in battery savings mode, it drains even less per hour. I haven't ran normal mode long enough to see how it drains compared to others. One thing though, web surfing drains battery just as fast as gaming.
BarryH_GEG said:
I ask because how can a game be optimized for Tegra if to the OS all chips are treated the same?
Click to expand...
Click to collapse
I hate quoting myself but I found the answer on Nvidia's website. Any otimizations are handled through OpenGL. So games written to handle additional calls that Teg2 can support are making those calls through OpenGL with the OS (I'm guessing) used as a pass-through. It would also explain why Tegra optimized games fail on non-Teg devices because they wouldn't be able process the additional requests. So it would appear that Teg optimization isn't being done through the OS. Again, correct me if I'm wrong.
BarryH_GEG said:
That's the way I'd guess it would work. I don't think Android addresses different chips differently. I'd assume it's up to the SoC to manage the incoming instructions and react accordingly. If Android was modified for dual-core, I don't think it diffentiates between the different implementations of dual-core chips.
Click to expand...
Click to collapse
I did some research on it; here's what Nvidia say:
The Android 3.x (Honeycomb) operating system has built-in support for multi-processing and is
capable of leveraging the performance of multiple CPU cores. However, the operating system
assumes that all available CPU cores are of equal performance capability and schedules tasks
to available cores based on this assumption. Therefore, in order to make the management of
the Companion core and main cores totally transparent to the operating system, Kal-El
implements both hardware-based and low level software-based management of the Companion
core and the main quad CPU cores.
Patented hardware and software CPU management logic continuously monitors CPU workload
to automatically and dynamically enable and disable the Companion core and the main CPU
cores. The decision to turn on and off the Companion and main cores is purely based on current
CPU workload levels and the resulting CPU operating frequency recommendations made by the
CPU frequency control subsystem embedded in the operating system kernel. The technology
does not require any application or OS modifications.
Click to expand...
Click to collapse
http://www.nvidia.com/content/PDF/t...e-for-Low-Power-and-High-Performance-v1.1.pdf
So it uses the existing architecture for CPU power states, but intercepts that at a low level and uses it to control the companion core/quad-core switch?
Edit: I wonder if that means that tinkering with the scheduler/frequency control would allow the point at which the companion core/quad-core switch happens to be altered? If the OP is correct, this might allow the companion core to be utilised less if an increase in "smoothness" was desired, at the cost of some battery life?
Mithent said:
I wonder if that means that tinkering with the scheduler/frequency control would allow the point at which the companion core/quad-core switch happens to be altered? If the OP is correct, this might allow the companion core to be utilised less if an increase in "smoothness" was desired, at the cost of some battery life?
Click to expand...
Click to collapse
So what we guessed was right. The OS treats all multi-cores the same and it's up to the chip maker to optimize requests and return them. To your point, what happens between the three processors (1+1x2+1x2) is black-box and controlled by Nvidia. To any SetCPU type program it's just going to show up as a single chip. People have tried in vain to figure how to make the Qualcomm dual-core's act independently so I'd guess Teg3 will end up the same way. And Nvidia won't even publish their drivers so I highly doubt they'll provide any outside hooks to control something as sensitive as the performance of each individual core in what they're marketing as a single chip.
[/COLOR]
Do you have Pulse installed? A bunch of people using it were reporting stuttering where their lower powered devices aren't. If you run it at full speed, does it stutter? One of the hypothesis is that it's the core's stepping up and down that's causing the stuttering.[/QUOTE]
I have been running mine in balanced mode, have had pulse installed since day one, no lag or stuttering in anything. games, other apps work fine.
Well my phones when clocked at 500 so I wouldn't be surprised
Sent from my VS910 4G using xda premium
So in 2011 we have Tegra 2, in 2012 we have Tegra 3 so my questions is what will come in 2013? Octo-core or an improved version of quad core cpus?
Fasty12 said:
So in 2011 we have Tegra 2, in 2012 we have Tegra 3 so my questions is what will come in 2013? Octo-core or an improved version of quad core cpus?
Click to expand...
Click to collapse
Well as octo core desktop CPUs havnt really caught on yet I would guess just better quad cores likely with more powerful GPUs
Tegra 3 is already very powerful, presuming the will increase ram and make them more battery efficient or even higher clock speed. 12 core tegra gpu is pretty amazing already and anything better must be godly
Sent from my HTC Desire using xda app-developers app
If u mean for mobile platform , Will we really need beyond Quad core, having seen how SGSIII is smoothly running with it, beyond that what more perfection ( yaa still more can be expected) and speed u will need to do ur work . As known Android use other cores on need basis , why u need to see ur 2-3 cores never used.. i think its just more curiosity n to have more advaced/latest will be the only reason to have such high cpu on ur mobile..
What I like to see is ups in RAM installed and lows in RAM usage by system...
Sounds like octo-mom..the debate.lives on.. battery vs performance...but to answer your question I think it would be hexa-core which is 6..let's wait and see what is to come...
Sent from my SGH-T989 using Tapatalk 2
s-X-s said:
If u mean for mobile platform , Will we really need beyond Quad core, having seen how SGSIII is smoothly running with it, beyond that what more perfection ( yaa still more can be expected) and speed u will need to do ur work . As known Android use other cores on need basis , why u need to see ur 2-3 cores never used.. i think its just more curiosity n to have more advaced/latest will be the only reason to have such high cpu on ur mobile..
What I like to see is ups in RAM installed and lows in RAM usage by system...
Click to expand...
Click to collapse
I agree. Cores are at there peak right now. The amount of CPU power we have especially in the higher end phones is enough to acomplish many, many things. RAM is somewhat of an issue especially since multitasking is a huge part of android. I really thing a 2gb RAM should be a standard soon. Also, better gpu's won't hurt
Sent from my HTC T328w using Tapatalk 2
If they decide to keep going on the core upgrade in the next two or so years, I see one of two possibilities happening:
1) Dual Processor phones utilizing either dual or quad cores.
or
2) Hexacore chips since on the desktop market there's already a few 6-core chips (though whether or not they would actually be practical in the phones architecture, no clue).
Generally speaking whatever they come out with next will either need a better battery material, or lower power processors.
I mean I'm pretty amazed by what my brother's HTC One X is capable of with the quad core, and here I am still sporting a single-core G2. But yes I would like to see more advancement in RAM usage, we got a nice bit of power, but how bout a standard 2GB ram for better multitasking?
I believe 2013 will be all about more efficient quad-cores.
May i ask what going from 1gb to 2gb will improve? Loading times?
hello everyone, could you tell me what is cuad core?
Quad core means that a processor has four processing units.
Because there are more, that means that a process, theoretically, gets executed 4 times faster.
Read more about it: http://simple.wikipedia.org/wiki/Multi-core_processor
Maybe i7 in mobile devices?
I'm sure it will stay at quad core cpu's, anything more is just overkill. They may introduce hyperthreading. It's going to boil down to efficiency.
Sent from my SPH-D700 using xda premium
I'd say the future lies in more efficient use of processors. Right now, Android is still far from optimized on multi-core processor-equipped devices. Project Butter is the start of a great movement by Google to optimize the operating system. Hopefully it spreads out to other OEMs and becomes the main focus for Android development.
Improving and optimizing current processors is the way hardware companies should go.
In my opinion, processor development is out running battery development. Optimized processors could reduce power consumption while preserving excellent speed and usability.
Sent from my Transformer TF101 using Tapatalk 2
building processors on more efficient ARM architectures is going to be the way to go from what I see......throwing four less efficient cores at a problem is the caveman method to dealing with it.....looking at you Samsung Exynos Quad based on tweaked A9 cores.....
the A15 based Qualcomm S4 Krait is more efficient on a clock for clock core for core basis and once the software catches up and starts using the hardware in full capacity, less more efficient cores will be preferred
I dont see anything beyond quads simply because they havent even scratched the surface of what can be done with a modern dual core processor yet.......throwing more cores at it only makes excuses for poor code.....i can shoot **** faster than water with a big enough pump......but that doesn't mean that's the better solution
We don't need more cores! Having more than 2 cores will not make a difference so quad cores are a waste of space in the CPU die.
Hyperthreading, duh.
More ram. Got to have the hardware before the software can be made to use it.
With the convergence of x86 into the Android core and the streamlining of low-power Atom CPUs, the logical step would be to first optimize the current software base for multi-core processors before marketing takes over with their stupid x2 multiplying game...
Not long ago, a senior Intel exec went on record saying that today, a single core CPU Android smartphone is perhaps better overall performing (battery life, user experience, etc) than any dual/quad-core CPU. Mind you, these guys seldom if ever stick out their neck with such bold statements, especially when not pleasing to the ear...
For those interested, you can follow this one (of many) articles on the subject: http://www.zdnet.com/blog/hardware/intel-android-not-ready-for-multi-core-cpus/20746
Android needs to mature, and I think it actually is. With 4.1 we see the focus drastically shifted to optimization, UX and performance with *existing/limited* resources. This will translate to devices beating all else in battery life, performance and graphics but since it was neglected in the first several iterations, it is likely we see 4.0 followed by 4.1 then maybe 4.2 before we hear/see the 5.0 which will showcase maturity and evolution of the experience.
Just my 2c. :fingers-crossed:
I do not yet have a Nexus 7 to test this with. You use this at your own risk!
This is the first real kernel work I've done, so don't be surprised if it doesn't work. I've only provided a boot.img as fastboot is easy enough to use on the Nexus 7.
Features (If it works):
CPU OC to 1.7GHz maximum
CPU over volt to hopefully reach 1.7GHz
GPU OC to 600MHz
Simple IO scheduler
SmartAssV2 CPU governor
The boot.img is attached. Source can be found at my github.
If anyone here has a Nexus 7 it would be very helpful to know if it works. I should have mine soon though. If it works well, enjoy. Feedback is always welcomed, as are benchmarks. Thanks.
Removed link until fixed!
This is scary looking, an untested Overclock that's never been run on the hardware before.
I'm guessing that the T30L is just a speed binned T30 and as such this shouldn't damage it. The same overvolt (and higher) has been successful on the T30 to get even higher clocks (1.8GHz). I would test this given hardware, however I don't yet have my Nexus 7.
ben1066 said:
I'm guessing that the T30L is just a speed binned T30 and as such this shouldn't damage it. The same overvolt (and higher) has been successful on the T30 to get even higher clocks (1.8GHz). I would test this given hardware, however I don't yet have my Nexus 7.
Click to expand...
Click to collapse
This sounds interesting. Especially the 600mhz gpu OC but may I ask if you are thinking of implementing some kind of app interface to control gpu clock and voltages etc like Extweeks on google play please? As I am guessing a lot of people won't be able to go to 600mhz stably, so a way to change the OC to something like 520mhz (to bring it to T30 speed) would be a good option
I've seen voltage tweaks controlled from userspace on other devices but not the GPU clock. I'd like to get it working first, then I guess I'll look at such things, especially if there is interest.
Cel1084 said:
This is scary looking, an untested Overclock that's never been run on the hardware before.
Click to expand...
Click to collapse
you go first!
bencozzy said:
Glados kernel on the galaxy nexus allows gpu oc control.
Click to expand...
Click to collapse
Siyah kernel for the galaxy s2 and galaxy s3 both let you control gpu clock speed and voltages, might be cool to have something similar
I don't even have my Nexus yet, and i'm already downloading things to flash to it, hahah. Will report back once Google ships to the US!
if this kernel works can we control the clocks with antutu or similar?
The CPU clock should be controllable, and I'm working on making the overvolt controllable. The GPU clock is not yet controllable, and I'm not so sure where to start on that.
ben1066 said:
The CPU clock should be controllable, and I'm working on making the overvolt controllable. The GPU clock is not yet controllable, and I'm not so sure where to start on that.
Click to expand...
Click to collapse
you should put the gpu clock to 520mhz arnt t30l 413mhz stock and kai would be even slower assuming its the budget tegra3 soc
Right, here's the thing. I've spoofed the SoC speedo ID to be that of the standard T30, however, without looking through with a fine tooth comb, it seems that the top that that id goes is 600MHz. In usage, it may be 520MHz, but I'm not sure. In addition I'm fairly sure these are just speed binned, and can probably run at the higher clocks if we just add a bit more voltage, or they get a little hotter. If anyone can tell me if this actually works, then I can adjust either way.
Look at tegra3_dvfs.c, line 256-262. It seems to indicate a maximum of 600MHz.
This should be helpful to you. tegra3 technical reference manual. everything there is to know about all variants of the chip. how it works, what its capable of, schematics, diagrams, chip layout, etc,,
http://db.tt/vWWou2Fu
Thanks but I already have access to NVidia's Tegra portal, which includes the TRM for Tegra 2 and Tegra 3. I'm hoping I shouldn't have to mess with it that low level
I don't understand why anyone would want to overclock a Tegra3, which is plenty fast enough already, especially when they have never even touched the device.
Also, I don't understand why anyone with any sense would use Simple IO scheduler, which has a higher latency and lower throughput than deadline, or even the bloat that is CFQ for that matter.
And finally, I don't understand why any real 'developer' would release something like this without testing it, especially with possibly dangerous overclocking and overvoltage settings. Only on XDA...
With all due respect, you should remove it until you have tested it *yourself* and confirmed that it doesn't make your Nexus 7 vanish in a cloud of smoke.
When I feel the need the need for speed owww.
_thalamus said:
I don't understand why anyone would want to overclock a Tegra3, which is plenty fast enough already, especially when they have never even touched the device.
Also, I don't understand why anyone with any sense would use Simple IO scheduler, which has a higher latency and lower throughput than deadline, or even the bloat that is CFQ for that matter.
And finally, I don't understand why any real 'developer' would release something like this without testing it, especially with possibly dangerous overclocking and overvoltage settings. Only on XDA...
With all due respect, you should remove it until you have tested it *yourself* and confirmed that it doesn't make your Nexus 7 vanish in a cloud of smoke.
Click to expand...
Click to collapse
Our Tegra 3 CPU is a lower clock version that the normal T30, it's the T30L. I have no doubt that this will not damage your device, the voltages used are still less than used by some TF201 ROMs (the TF201 uses the T30). I included Simple IO scheduler since it is something that seems popular, latency isn't the only thing that matters (read http://www.vincentkong.com/wiki/-/w...42041E#section-Android+IO+Schedulers-Deadline). I have seen benchmarks that show both SIO and deadline as better than each other, it depends what metric you record. I didn't remove CFQ, it's not that I've added it. The scheduler can be changed if you so desire anyway.
I have not provided a simple flash package and I've clearly stated in red writing that this is UNTESTED. I do not have the device, and it is yes untested however I didn't see the point on keeping something potentially useful private. If you have the knowledge to use fastboot to flash a boot.img, you probably know how to flash back the old one too.
_thalamus said:
I don't understand why anyone would want to overclock a Tegra3, which is plenty fast enough already, especially when they have never even touched the device.
Also, I don't understand why anyone with any sense would use Simple IO scheduler, which has a higher latency and lower throughput than deadline, or even the bloat that is CFQ for that matter.
And finally, I don't understand why any real 'developer' would release something like this without testing it, especially with possibly dangerous overclocking and overvoltage settings. Only on XDA...
With all due respect, you should remove it until you have tested it *yourself* and confirmed that it doesn't make your Nexus 7 vanish in a cloud of smoke.
Click to expand...
Click to collapse
seriously harsh man, just because you don't understand doesn't mean its wrong, or right for that matter
ben1066 said:
Our Tegra 3 CPU is a lower clock version that the normal T30, it's the T30L.
Click to expand...
Click to collapse
I take it you understand why similar chips are rated at various speeds for different devices? Because they are designed with a lower thermal output and / or the cooling characteristics / power characteristics of the device are different. The T30L has lower speed apps processors, lower speed GPU and lower speed memory. All in all, it will pump out much less heat than a T30.
I have no doubt that this will not damage your device, the voltages used are still less than used by some TF201 ROMs (the TF201 uses the T30).
Click to expand...
Click to collapse
You don't *know* that it won't damage someones device, you are assuming that it won't. The likelihood is that it probably won't, but would you stake your life on it? I wouldn't, and I've been doing Android kernel development for some time.
Also, this isn't the TF201, and it isn't the T30. It is a different device with different thermal characteristics and a different SoC, you can't compare them like that.
I included Simple IO scheduler since it is something that seems popular, latency isn't the only thing that matters
Click to expand...
Click to collapse
Latency of reads and writes and throughput are the only 2 things which matter (and I mentioned both), and SIO is poor at both of them. Justin Bieber is popular, but he's still ****, so including something which is popular isn't really a good reason.
---------- Post added at 06:44 PM ---------- Previous post was at 06:33 PM ----------
foxorroxors said:
seriously harsh man, just because you don't understand doesn't mean its wrong, or right for that matter
Click to expand...
Click to collapse
Harsh perhaps, but I prefer honest. Necessary, most certainly.
It is stupid and irresponsible to release something which is untested and potentially dangerous as it isn't fair on the poor muppet that flashes it and then f**ks their device up.
It has only been released because some 'developer' wants to make his epenis bigger by releasing something for a brand new device on XDA. Not that I am saying that he is the only one, there's plenty of others that do it, but as I have one of these on order I am taking an interest in these threads and was quite surprised with what I saw.
As someone who has done kernel development for some time now, I would never dream of releasing something I haven't tested thoroughly myself, or which I have got a trusted tester to thoroughly test, but hey, this is XDA and the standards are low.
ben1066 just out of curiosity may I ask how the gpu scales frequencies on the Tegra 3 t30l please? As I am used to the galaxy s2 and s3 where you have numerous frequency steps like 166mhz, 260mhz, 350mhz and 440mhz and you have an up and down threshold to govern whether you jump up or down the available frequencies, is this similar to how the gpu in works on the tegra 3 please?
Also when you say overclock the gpu, is it replacing 416mhz with 600mhz or is it adding an extra gpu frequency step after 416mhz, so 416mhz is still available to be used if needed? Sorry one last question, if the gpu does have frequency steps like other gpus, what ones are available for use please?
I am sorry to ask, I am just so curious about these questions, and I can't find them anywhere on the internet, so any help would be greatly appreciated. Thank you so much
Okay, so I'm REALLY anal about the speed of my phone, the slightest bit of stutter or lag from just the notification center itself really bothers me. I was wondering if someone could recommend some really good settings for my phone
I currently am running
JellyBam 6.3.0 (JB 4.2.2)
4Aces Kernel
I would like some good settings regarding governor, CPU Frequency, and any other things I can do including stuff in developer options, if that helps. Thanks!
It is likely that you will always have "some" degree of lag present in the note 1. Due in large part to our GPU. We are also limited in performance by our dual core CPU.
That being said, the closest to zero lag I've found, is using Flappjaxxx current JB AOSP build, (0225) combined with nova launcher, and his newest 3.0.9 ALT kernel.
Windows, transition, and animator settings to "off" in development settings.
Wheatley governor set to 384 min, 1.72 max.
system tuner app on system controls set to "recommended".
No over/undervolt.
forced GPU rendering in development settings.
These are my main settings, but yours will likely differ.
Happy tuning....g
^^Limited performance from "only a dual core" ...
Hardware is WAY ahead of software right now.
The second core is offline most of the time due to no load and developers of apps not fully understanding how to utilise multiple threads...
Adding more cores on top of an unused core ain't really gonna help much.
And yet we cant even stream a quality youtube video above 22 FPS, all the while the MSM8660 specs boast a capability of nearly 60 FPS with the Adreno 220 GPU.
So my question is, Are we seeing reduced performance from the CPU, or the GPU. It cant be all software, as we see the reductions when ranging software from GB to JB.
Drivers are in play of course, but I can't hardly imagine a piece of code so poorly made, as to reduce output capacity by 50%.
Not doubting you brother because I "know" you know your way around this machine, and because we so many times have traveled the same paths of thought. And it's entirely possible I'm missing a critical point here. But damn...I wanted the stated video speeds, and I'm not getting what Qual and company promised me. and in a direct comparison to the note2 quad, it's night and day as I watch the same video on my note1 next to my wifes 2. The odds are in favor of 2 cores running low speed on the quad core unit, as opposed to our note 1 running a single core wide open until the second one is needed. That of course was the basis for my statement.
OP can tweak for many great improvements, but I personally feel like we were duped on the claimed output of the 8660.....g
Just get a wife - then the phone lag will seem so trivial.
LOL .....he speaks the truth ....g
Hello,
i just got my Z5C yesterday and so far i´m more than happy. But there is one issue:
I use the AOSP Full disk encryption on the phone but it seems like the native Qualcomm hardware cryptographic engine doesn´t work well - i benchmarked the internal storage before and after, here are the results:
Before: read ~ 200 MB/s write: ~ 120 MB/s
After: read ~ 120 MB/s write: ~ 120 MB/s
(Benchmarked by A1 SD Bench)
I´m using a FDE on my windows 10 Notebook with an e-drive resulting in like 5% performance loss. The decrease in read-speed on the Z5C is noticable. What do you think, is there something wrong or is this a normal behaviour?
Cheers
I don't know if this helps, but it seems that the Nexus 5X and 6P won't use hardware encryption according to this:
DB> Encryption is software accelerated. Specifically the ARMv8 as part of 64-bit support has a number of instructions that provides better performance than the AES hardware options on the SoC.
Click to expand...
Click to collapse
Source: The Nexus 5X And 6P Have Software-Accelerated Encryption, But The Nexus Team Says It's Better Than Hardware Encryption
So maybe, Sony is following the same path...
Sadly they don't, it seems like the write-speed decrease is just on the same level as the N6 back then. Let's hope that they include the bibs in the kernel by the marshmellow update.
Why would they use Qualcomms own crappy crypto engine, if the standard Cortex-A57 is really fast with AES thanks to NEON and possibly additional, newer optimizations/instructions? AFAIK the latter are supported in newer Linux kernels per default, so there's no need to use additional libraries to enable support or the Qualcomm crypto stuff.
But it would be nice, if someone with actual insight and detailed knowledge about this could say a few words for clarification.
Neither i got insight nor big knowledge, but i benchmarked the system and like 60% loss in reading speed doesn't feels like a optimized kernel either :/
Qualcomm is a no go. On android plaform, only Exynos 7420(not sure about 5xxx series) real get used h/w encry and decry engine and no speed down.
TheEndHK said:
Qualcomm is a no go. On android plaform, only Exynos 7420(not sure about 5xxx series) real get used h/w encry and decry engine and no speed down.
Click to expand...
Click to collapse
That's not only off topic, it's also wrong. The Exynos SoCs don't have a substantially different crypto engine or "better"/"faster" crypto/hashing acceleration via the ARM cores. If anything, the Samsung guys are smart enough to optimize their software so it makes use of the good hardware. This seems to be missing here, but for no obvious reason.
xaps said:
That's not only off topic, it's also wrong. The Exynos SoCs don't have a substantially different crypto engine or "better"/"faster" crypto/hashing acceleration via the ARM cores. If anything, the Samsung guys are smart enough to optimize their software so it makes use of the good hardware. This seems to be missing here, but for no obvious reason.
Click to expand...
Click to collapse
I agreed all ARMv8-A cpu support hardware AES and SHA. Both Exynos 7420 and S810 should also got that ability but it turns out doesn't work on Z5c now which is a fact. I'm sure S6 got it working but not sure about on other S810 phones or might be Qualcomm missing driver support.
TheEndHK said:
Both Exynos 7420 and S810 should also got that ability but it turns out doesn't work on Z5c now which is a fact.
Click to expand...
Click to collapse
Please show us the kernel source code proving that fact.
What you call "fact" is the result of a simple before and after comparison done with a flash memory benchmark app run by one person on one device. To draw the conclusion that the only reason for the shown result is that the Z5(c) can't do HW acceleration of AES or SHA is a bit far-fetched, don't you think?
xaps said:
Please show us the kernel source code proving that fact.
What you call "fact" is the result of a simple before and after comparison done with a flash memory benchmark app run by one person on one device. To draw the conclusion that the only reason for the shown result is that the Z5(c) can't do HW acceleration of AES or SHA is a bit far-fetched, don't you think?
Click to expand...
Click to collapse
I've got a S6 and no slower after encry/decry and we had a thread discussing about it on S6 board.
I don't own a Z5c now bcoz my living place HK not yet started to sell it(I come to here bcoz considering to sell my S6 and Z1c and swap to Z5c later) so I can't test it but according to OP, there is a substantial slow down.
All ARMv8-A should support hardware AES/SHA, it is not just a cached benchmark result on S6. That's real.
A few things to ponder...
This is confusing. I was always under the impression that decryption (reads) are usually a tad bit faster then encryption writes. This at least seems true for TrueCrypt benchmarks. But that may be comparing apples and oranges.
A few thoughts...
In some other thread it was mentioned that the Z5C optimizes RAM usage by doing internal on the fly compression / decompression to make very efficient usage of the RAM. As cryptotext usually is incompressible could this be a source of the slowdown on flash R/W. Could this be a source of the problem (either by actual slowdown or confusing the measurement of the benchmarking tool?)
These days the SSD flash controllers also do transparent compression of data before writing to reduce wear on the flash. If you send a huge ASCII plaintext file into the write queue the write speed will be ridiculously high, if you send incompressible data like video the write speed rate goes way down. This happens on hardware level, not taking any cryptop/decrypto operations on the OS level into account.
Is there maybe a similar function in todays smartphone flash controllers?
Can I ask the OP, in what situations do you notice the slower read rate on the crypted device? Not so long ago when spinning rust disks were still the norm in desktop and laptop computers read rates of 120 MB were totally out of reach. What kind of usage do you have on your smartphone that you actually notice the lag? Is it when loading huge games or PDF files or something similar?