currently the CPU frequency is limited at 1.51GHz. Is it possible to get the CPU running at 2GHz? Specification says 2GHz are possible. How can this be achieved under Linux with VIM2?
Do i need to change the cpu_dvfs_tbl only or must also something be change inside the linux kernel?
Yes, it looks like marketing bla bla.
But HardKernel did push AMLogic to release an unlimited firmware (bl30.bin) . And the got a new one from AMLogic with all frequencies unlocked up to 2 GHz.
So maybe ābl30.binā for VIM2 has already a complete table of frequencies or Khadas stuff can push AMLogic to get new ābl30.binā like HardKernel did.
Nope, itās 1448 MHz max and also as soon as all 4 big cores are busy at the same time this will be decreased to just 1200 MHz.
Pretty easy to test this out BTW with benchmarks like sysbench who scale linear with count of CPU cores. So simply try out these three tests and compare the results to see how real cpufreq clockspeeds look like:
sysbench --test=cpu run --num-threads=1 --cpu-max-prime=20000
sysbench --test=cpu run --num-threads=2 --cpu-max-prime=20000
sysbench --test=cpu run --num-threads=4 --cpu-max-prime=20000
tested the mhz tool on a vim2pro (with performance cpufreq governor, cpufreq-info reporting 1.51Ghz on cores 0-3, 1000 Mhz on cores 4-7), hereās the result:
@Gouwa have you got any thoughts on this thread? Dont suppose you have talked to amlogic about it? Is it possible to get a different bit of code from them to adjust it? Thanks!
Iāve got another process eating up all other cores, I think thatād be equivalent to sysbench, but I can give sysbench a try.
Iāve seen the other thread as well. Iāve been observing various eyebrow-raising results when using various s912 boards, and this indeed does raises some questionsā¦
Well, while sysbench is a pretty lousy tool to measure hardware performance of different architectures itās really great when doing these sorts of tests since the whole job is done inside the CPUās caches so not influenced by memory bandwidth/latency and also scaling linearly with count of CPU cores (so you can compare --num-threads=1 with --num-threads=8 and if the latter number is not 8 times lower you know thereās something wrong)
I posted over there a simple script able to repeat @balbes150ās tests from last year that clearly showed back then that with multithreaded CPU loads clockspeeds further decrease. Should be just a matter of minutes to repeatā¦
Back then when @balbes150 thankfully tested for me I was not aware that S912ās boot blob wants to play little.LITTLE (itās an octa-core A53 design with two little clusters so thereās no big.LITTLE here, itās just Amlogic for whatever funny reasons shipping this SoC with a firmware that artificially limits 4 CPU cores to 1.0 GHz and 4 CPU cores to 1.4 GHz while faking the clockspeed readouts of the faster cluster for whatever reasons)
So when a load like sysbench is running that neither depends on external memory bandwidth nor on anything else happening outside the CPU cores the result with an 8 thread load is an average 1.2 GHz clockspeed and that was exactly what sysbench reported back then.
In reality the situation with S912 is much worse since while with a full load on all 8 cores at least all 4 āfastā cores at 1.4 GHz are utilized with normal workloads that are single-threaded it can happen easily that a demanding task ends up on one of those bottlenecked CPU cores then limited to 1000 MHz.
On average tasks that are single-threaded are slower on Vim 2 than on Vim since on the latter all 4 CPU cores are allowed to clock at up to 1.4 GHz while on Vim2 for whatever funny reasons the scheduler keeps tasks on the artificially bottlenecked CPU cores and limiting single-threaded loads to 1 GHz.
It seems to me that what probably happened is AML set out with the intention of releasing a real big little design, but under testing discovered that the SOC die was way to flakey at these speeds, with throttling and unacceptably high failure rates. Its bad enough that there chip can reach 90C as it is currently configured. Performance = heat and thats basic physics, and the cost of providing an adequate cooling solution is simply beyond the margins of their target market. Instead of admitting that their design was flawed they simply lied and made their software lie.
However none of this really matters to 99.9% of their user base since the chip is well capable of running Android as a media player at performance way beyond just about all of the similarly priced products. Also in the target market of media players performance of each CPU is totally unimportant - but the ability to do multiple tasks in the background competently and in parallel is critical - hence eight low spec CPUās makes perfect sense and high performance high speed cores make none.
This just shows what an absolutely shitty company AMLogic is. They have shat on their reputation in the western market and it seems that they have abandoned most plans to stay within that market. Why , because they have spotted an opportunity to sell tightly controlled TV boxes to the domestic Chinese market - with the software locked down and the hardware optimised for this sole purpose.
Hobby SOC userās are about as important to AML as a nat on the arse of an elephant.
If you want a decent product then move along and spend a bit more money on one of the Samsung based chips.
Its all a bit disgusting really. Its bad enough that I have sworn off ever buying a AML SOC product again and am fairly lairy of touching any arm based product that isnāt a Android phone (where they excel). Intel based SOC products are infinitely better performance and peripheral support wise, and are getting to be cost and energy competitive with the ARM based SOC chips and that is where my money will go in the future.
Thanks a bunch. So even 7-zipās benchmark mode is sufficient to confirm Amlogic cheating with clockspeeds
On the other hand for whatever reasons the āper core per GHzā performance also differs a lot between both clusters:
0-3: 3999 7-zip MIPS at 1415 MHz ā 707 per core @ 1 GHz
4-7: 2270 7-zip MIPS at 1000 MHz ā 568 per core @ 1 GHz
I fail to interpret the numbers since especially decompression speed is almost twice as fast on cores 0-3 (see comments at the bottom of https://www.7-cpu.com)
@g4b42 In case time permits are you able to run sbc-bench neon on your Vim2?
We started to assemble some benchmarks over there https://github.com/ThomasKaiser/sbc-bench and included a lot of monitoring to get a clue whatās going on on platforms that behave somewhat strange (RPi and Amlogic S905X/S912 as best examples).