Safe pi overclocks via openelec...post your settings
#16
With my tests that I've been doing with the Pi. I've found the following information.

With extra overclock , these are mine

arm 1160
core 580
sdram 700
over voltage 8
over voltage sdram 8

(also added in other things to make this work like avoid_pwm_pll=1 , disable_pvt=1 (for the ram) )

yeah with this overclock if the tempreture reaches more than around 55. It will just freeze

Also you won't last long with these tempretures if you don't have adequte way of getting rid of the heat. I use lots of heatsinks and have it vertical.

You won't heatsinks but from what I've tested you would if you want to squeeze slightly extra juice.
Even with these settings I don't get past 51-52 on full load, medium load 48, and idle on 46 (with heatsinks). quite impressed with passive heating to get those tempretures to be honest.
Reply
#17
Mine is stable running for weeks with custom Gotham Build OpenElec. 8GB USB3.0 memory stick and class 10 sdhc card. Using a 5.1V 2.1amp power supply.

arm_freq=1100
core_freq=550
h264_freq=350
isp_freq=0
v3d_freq=350
sdram_freq=600
over_voltage_sdram=6
over_voltage=8
hdmi_force_hotplug=1
disable_overscan=1
hdmi_ignore_cec=1
temp_limit=80
avoid_pwm_pll=1
Reply
#18
Latest Gotham build runs fine with these settings:

arm_freq=1075
core_freq=500
sdram_freq=500
over_voltage=6

... anything higher and I get lock-ups.

@mattmartinolc, I have a similar setup and I've tried using your settings for most of today but I find the Openelec experience worse; artwork is slower to load, videos take longer to start, menues take longer to open. Also, CPU usage is reported as %100 even when at idle.

Edit:

@mattmartinolc, I now realise that my probelms were related to the Tvheadend PVR service. Your settings are great!
Reply
#19
Need the good power supply to pull it off. 2.1 amp more than handles everything. I have also recently cut up some heat sinks and mounted them on and cooled it with a 5 volt fan I salvaged out of an old hub I no longer use. the fan is powered by a little universal adapter (I can hook it up to pins 1 and 3 of the Pi itself but the Pi wouldn't like the little jolts)

Now that I have the cooling in place, I am going to see how far I can push it. At the current settings I posted above, the temp sits around 90 degrees fahrenheit at idle and the hottest I have seen it get under load is 104
Reply
#20
OK so I have been inspired by this forum to push the envelope a bit. My config file is currently 192MB to the GPU and the rest as follows (I have 2 heat sinks and a fan on here too)

arm_freq=1130
core_freq=560
h264_freq=360
isp_freq=0
v3d_freq=360
sdram_freq=700
over_voltage_sdram=6
over_voltage=8
temp_limit=80
avoid_pwm_pll=1

So far is stable and playing an HD movie and the temp is holding at about 99Fahrenheit.
Reply
#21
What baffles me (not hard) is that If I OC my PI to 900/500/500 it crashes almost instantly, however if I try 1020/500/500 it boots and is stable as hell. This all done using a class 6 SD card
Reply
#22
(2014-01-24, 21:28)mattmartinolc Wrote: h264_freq=360
isp_freq=0
v3d_freq=360
avoid_pwm_pll=1

The h264_freq is rather odd, or possibly broken.

It seems that in order for the h264 block to hit 360 (as measured with "vcgencmd measure_clock h264") you need to set v3d_freq to 360 (and avoid_pwm_pll=1, otherwise you get 333MHz).

Setting h264_freq alone (with/without avoid_pwm_pll) results in the h264 block still being capped at 250MHz, ie. the h264_freq setting has no impact on the maximum frequency measured by "vcgencmd measure_clock h264".

However if you set v3d_freq=360 (and leave hd264_freq at stock frequency, or any frequency you like it doesn't really matter - I tried 999MHz without a problem), then the h264 block will hit 360 - it's as if the h264_freq setting has no purpose, or is being ignored, and it's the v3d setting that is being applied to the h264.

I guess setting isp_freq=0 does no harm, as it's unlikely to be used in XBMC?

You can monitor your stats with bcmstat.sh and confirm if your Pi is going up and down through the frequency ranges you are setting, also keep an eye on temperature.

I've managed to hit 85C while not using extreme overclock (ARM 1000, Core 500, SDRAM 600, over_volts +4/+4) when running a stress test. If your Pi is stable during that test, it should manage anything you throw at it...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#23
By default core, h264, v3d and isp all share a PLL.
The PLL will be set to an integer multiple of the core clock (the largest N where 2*N*freq <= max_pll_freq, max_pll_freq defaults to 2400).

The other clocks will be set to pll_freq/(2*K) for the smallest integer K that doesn't exceed their specified frequency.
So the frequency you request may get quantised down.

When avoid_pwm_pll=1, the core and h264/v3d/isp use different plls.
The second pll has slightly different logic. It is set to the largest N where 2*N*freq > 600.
It also doesn't treat one of these clocks as the master, but allows whichever comes last to change it.
That actually seems wrong to me if a second clock change alters the PLL, the first clock will now be wrong.
I think I need to deem one of the clocks as the master which is set first, and will get an exact frequency, and the others may be rounded down.

In general on the Pi the v3d/h264 is rarely a bottleneck. I'd be surprised if xbmc ran any better with v3d/h264 overclocked.
However I'll have a tweak with the avoid_pwm_pll code path, as I think it could be improved.
Reply
#24
Thanks for the explanation. I can't say I've not noticed any difference with h264/v3d @ 360MHz compared with stock 250MHz. I just thought it odd that the h264_freq setting seemingly has no effect (at least, I've not managed to get it to do anything useful!) Thanks for taking a look, although I don't think there's any need to rush on this one!
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#25
Using a 5.0V 2A power supply and USB 3.0.

arm_freq=1100
core_freq=500
sdram_freq=600
over_voltage_sdram=6
over_voltage=6
force_turbo=1
hdmi_force_hotplug=1
hdmi_ignore_cec=1

Temps ~52ºC no cooling but I plan on buying some.
 
  • Intel NUC Kit DN2820FYKH ~ Crucial DDR3L SO-DIMM 4GB ~ SanDisk ReadyCache 32GB SSD ~ Microsoft MCE model 1039 RC6 remote
Reply
#26
MilhouseVH - that "bcmstat.sh" do I download and install that on my RPI or what do I do with this to see my stats? thanks!
Reply
#27
(2014-02-14, 00:42)LilSnoop40 Wrote: MilhouseVH - that "bcmstat.sh" do I download and install that on my RPI or what do I do with this to see my stats? thanks!

Yes, download the script from github, grant execute permission on the script with "chmod +x bcmstat.sh" and then execute it on the Pi.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#28
MilhouseVH, sorry but you lost me there. I did download it from github its a .zip file do I extract it then ftp it over then run. sorry I am not understanding what you said. do I install it like a normal addon?

Thanks
Reply
#29
(2014-02-14, 02:06)LilSnoop40 Wrote: MilhouseVH, sorry but you lost me there. I did download it from github its a .zip file do I extract it then ftp it over then run. sorry I am not understanding what you said. do I install it like a normal addon?

If you've downloaded the zip, just copy the bcmstat.sh file from the ZIP to your Pi and then apply the execute permission at the ssh command line. You could also download the raw source directly from github using curl or wget. bcmstat.sh is not an addon, it's a script that functions outside of XBMC - in fact, this script has nothing to do with XBMC!
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#30
MilhouseVH, thanks for the walk through. I got it
Reply

Logout Mark Read Team Forum Stats Members Help
Safe pi overclocks via openelec...post your settings0