12
Return to list Post new posts
Author: Vlad

Overclocking of OP+, my experience

[Copy link]
Published in 2015-11-19 01:41:00 | Show all floors
Edited by bronco at 2015-11-19 01:42
loboris replied at 2015-11-19 01:21
DRAM frequency is 672. "Out of memory" is because oom killer kills one of the threads. It occurs a ...

Thx again!

OK, to sum it up: 1.53 GHz heatsink+fan vs. without heatsink:
  1. sysbench (less is better):    123.3   183.7
  2. 7-zip (more is better):        2774    1924
  3. mbw -t0 (more is better):       396     407
  4. mbw -t1 (more is better):       756     769
  5. mbw -t2 (more is better):       718     633
Copy code

When throttling jumps in integer performance is really affected (especially see the comparison regarding avg/max below!) but DRAM nearly at all.

sysbench "per-request statistics":
  1.          min:                                 48.98ms                                                                                            
  2.          avg:                                 49.34ms                                                                                            
  3.          max:                                108.22ms
Copy code
vs.
  1.          min:                                 49.00ms
  2.          avg:                                 73.48ms
  3.          max:                                446.61ms
Copy code
This will be the first thing when the OPi PC arrives: Trying to figure out whether decreasing DRAM frequency helps with increasing overall performance (when we're talking about a typical 'SBC setup' with an efficient heatsink and avoiding a fan)

16

threads

104

posts

989

credits

Senior member

Rank: 4

credits
989
Published in 2015-11-19 08:50:33 | Show all floors
Ok, reading my post i admit i made a bit of confusion (sometimes my memory fault)
Here is an extract of a conversation i had a couple of years ago with a friend (thanks Pat!!) which explained me what i tried to say in a bad way, hope this may be of some help
Now the Mali clock freq is taken from PLL4, which is set here: ./arch/arm/mach-sun4i/clock/clock.c to 960MHz.  The divisor is taken from the mali_clkdiv setting in script.bin.  If you want to play around with the setting, I'd suggest you change the line

        tmpSclk->clk->rate  = 960000000;

with one that reads PLL4 from the script.bin (this is done by android and is in all the A20 FEX files).  Then you can set the clock and divisor at boot time.

Note that it typically maxes out below 400MHz.  Also note that this clock is shared with the video decoder (cedarx) on A10, which also maxes out below 400MHz. It uses a different divider and selects it automatically based on the PLL4 clock rate, and limits the cedarx clock to 320MHz. So if you set PLL4 to 400MHz, the cedarx driver will not set its divider less than 2, and the max clock on cedarx will then be 200MHz
.....
if i have understood, the pll4 and the mali_clkdiv are the governors of gpu clock (960/3=320). Decreasing these values, i could run mali at 200mhz and increase the cpu clock.
But reversing the mod, i coud overclock the gpu   May be this right?
.....
Correct.  GPU and CPU are clocked independently.  Only the GPU and video decoder are on the same clock, but with different dividers.


OrangePi A20, with Qbee-X_testing

Still waiting for refund/replacement of no working op+2e bought on 11/11 >_<...really serious company
Published in 2015-11-19 19:13:47 | Show all floors
tokka replied at 2015-11-19 08:50
Ok, reading my post i admit i made a bit of confusion (sometimes my memory fault)
Here is an  ...

Yes, on SoCs CPU and GPU cores might share the same clock source. But they won't share 'frequencies'. And there's no Allwinner SoC available where the ARM core's maximum clockspeed  can be increased "up to" 2 GHz. That's still marketing chitchat and should be divided by two.
Allwinner SoCs aren't fast. They're cheap instead
12
Return to list Post new posts
You need to log in before you can reply login | Register

Points Rule

Quick reply Top Return list