CPU frequency up to 2GHz?


#1

Hi,

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?

Kind regards
Andreas


#2

It seems the hardware is limited to 1.5Ghz and it is not possible to over clock it further.
https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/

Shoog


#3

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.

Andreas


#4

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

And here is a nice tool from the guy who discovered Amlogic cheating on us wrt cpufreq: https://www.cnx-software.com/2018/01/31/pine-h64-development-board-features-allwinner-h6-processor-gigabit-ethernet-usb-3-0-and-pcie-for-26-and-up/#comment-551410

So the interesting questions is not how to get 2 GHz but how to get even 1.5 GHz in reality :slight_smile:


#5

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:

root@vim2p:~# taskset -c 0 ./mhz
count=645643 us50=22806 us250=114044 diff=91238 cpu_MHz=1415.294
root@vim2p:~# taskset -c 7 ./mhz
count=413212 us50=20676 us250=103364 diff=82688 cpu_MHz=999.449

S912 limited to 1200 MHz with multithreaded loads
#6

and for comparison, the same on a rk3399 sapphire ref board:

root@sapphire4:~# taskset -c 0 ./mhz
count=645643 us50=22808 us250=114053 diff=91245 cpu_MHz=1415.185
root@sapphire4:~# taskset -c 5 ./mhz
count=807053 us50=22425 us250=112149 diff=89724 cpu_MHz=1798.968

so it appears this tool is quite accurate indeed (cpufreq-info on rk3399 reports cores 0-3 at 1.42Ghz and cores 4-5 at 1.80Ghz)


#7

What’s the result with the cores loaded up? Same frequency or lowered to 1.2 as the post above suggests?


#8

about the same result… it’s certainly lower than the advertised 1.5Ghz, but not as low as 1200Mhz


#9

Good it isnt lowering to 1.2.

@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!


#10

So when you run sysbench --test=cpu run --num-threads=8 --cpu-max-prime=2000000 in another shell what are the results?

Did you see Underwhelming performance Khadas Vim2 Max in video rendering kdenlive ? Performance when running on the big cluster below RPi 3. That’s another ‘1200 MHz indication’ :wink:


#11

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…


#13

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…