Overclocking

[dom]

I don't have anything in the cpu0 dir "apt-get upgrade" didn't work have ran all the update and upgrades can overclock but can't get cpu frequency the widget shows 0 any help how to get this

What does "uname -a" report? What about "dmesg |grep cpufreq"?
Did you run raspi-config and choose overclock from menu?

[dom]

Does core speed affects anything else than ARM L2 cache ?

Well it makes the GPU core processor run faster.
Also the (shared by GPU and ARM) bus to SDRAM and peripherals runs faster.

[Cino]

Is it possible to read the value of the the SoC bit that gets flipped after your first overvolt? I have two RPi's and lost track of which one I was using to play around with overvolting.

Code: Select all

cat /proc/cpuinfo
...
Revision        : 1000002

will indicate the "warranty" bit at the top end of board revision. It's Bit 24.

When I run this my Revision: 1000003.. Correct me if i'm wrong, but my warranty bit has not been set.. Can't remember if I did overvolt or not... I want to say yes.

[0117blocky]

Thanks for this upgrade guys:)
I thought my Pi would crash as the onboard voltage is 4.74v at 700mhz.
But testing it in Turbo mode (1ghz) playing penguin puzzle, I had no issues.
I've now set it at 900mhz which I'm happy with as everything is just that little bit faster.
Thanks again
Mark.

[XarothBrook]

Right, I'm loving this new overclocking thing,

HOWEVER.

as per the documentation, it states you can use the *_min settings to set the minimum values.... in my case I want to scale up to 950mhz, but always have it at 800mhz....
this, however, doesn't work (anymore?)

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
700000

scaling up to max works though:

Code: Select all

for i in {1..10000} ; do set X 1; done && cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
950000

.. but once it's idle it'll drop back to 700...

any way to still keep it at 800 ?

[hojnikb]

Does core speed affects anything else than ARM L2 cache ?

Well it makes the GPU core processor run faster.
Also the (shared by GPU and ARM) bus to SDRAM and peripherals runs faster.

thx for reply. Apperently my SoC doesnt like too high core clock, as when i set more than 350, instability accurs. In quake for example it either crashes or i get stucked keypresses

[dms75]

Hi,

I think i might have found a bug or more likely an error in the documentation.

I have set the following values:

arm_freq=950
core_freq=374
sdram_freq=500
over_voltage=2

when idle it runs happily at arm 700, core 250 but when in turbo mode
when i enter
cat /dev/urandom | bzip2 > /dev/null &
the arm_freq goes up to 950 as it should, the core_freq goes to 374, still as expected, but the h264_freq is set to 224.4 instead of 280.5

If i understood the calculations correct the PLL should run at 374*6=2244 and if i divide 2244 by 250 i get 8.976. when rounded to the nearest even integer i should get a divisor of 8, not 10. so the resulting h264_freq should be 280.5 instead of 224.4, since i don't use avoid_pwm_pll.

Am i missing something?
Does it perhaps pick the resulting frequency which is nearer to 250 MHz instead? If so the documentation might need an (minor) update.

Ultimately i was looking for values where the turbo setting would also result in a slight increase for the h264 and related frequencies, by looking for suitable values I stumbled accross this behaviour, I did not intend the h264 frequencies to decrease in turbo settings.

So can anyone shed some light on how the divisor for the h264 frequency gets choosen?

Thanks in advance

dirk

[dom]

as per the documentation, it states you can use the *_min settings to set the minimum values.... in my case I want to scale up to 950mhz, but always have it at 800mhz....
this, however, doesn't work (anymore?)

_min values can't be increased above stock settings.

any way to still keep it at 800 ?

Only with force_tubo=1 and setting the warranty bit.
I'll think about allowing a non-overvolted _min overclock setting.

[dom]

the arm_freq goes up to 950 as it should, the core_freq goes to 374, still as expected, but the h264_freq is set to 224.4 instead of 280.5

If i understood the calculations correct the PLL should run at 374*6=2244 and if i divide 2244 by 250 i get 8.976. when rounded to the nearest even integer i should get a divisor of 8, not 10. so the resulting h264_freq should be 280.5 instead of 224.4, since i don't use avoid_pwm_pll.

Am i missing something?
Does it perhaps pick the resulting frequency which is nearer to 250 MHz instead? If so the documentation might need an (minor) update.

No, it rounds divisor up, and so frequency down. This means v3d/h264 may go down a little with overclock. However they are almost never a bottleneck, so it's unlikely to have an effect.
Currently the v3d/h264 doesn't increase when core increases, as it's usually not necessary, and ARM busy does not correlate closely with v3d/h264 busy.
However that is something I may tweak in a further update, to allow what you describe with gpu_freq=281 (but gpe_freq_min left at 250).

[XarothBrook]

I'll think about allowing a non-overvolted _min overclock setting.

that would be useful.. though a hard cap on the _min values would be needed to keep the chip cool (It'd suck if somebody tried to be smart and put the _min values to the same as the OC values...)

[Salamander]

Check out the blog post:
http://www.raspberrypi.org/archives/2008

and you'll understand the tweaks to overclocking behaviour that have been occurring over the last couple of weeks.

Note, that overclocking through raspi-config doesn't set your "warranty" bit. What sets the warranty bit now, is:

Code: Select all

(force_turbo || current_limit_override || temp_limit>85) && over_voltage>0

So, if you are manually overclocking and want to know what is "allowed", then stick to those config.txt options.
If you've already blown your warranty bit, or don't care, then feel free to change anything.

I seem to be enable to find the definition to current_limit_override, nor in this thread nor in the wiki. Please, could any body help.

[dom]

I seem to be enable to find the definition to current_limit_override, nor in this thread nor in the wiki. Please, could any body help.

It is descibed in the thread, but the forum search doesn't find it (so use google instead):
http://www.raspberrypi.org/phpBB3/viewt ... 25#p170793

[shalo]

Dom, it seems that overvolting and using the performance governor doesn't void the warranty. You might want to address this problem.

Also the new turbo mode (1000MHz ARM, 500MHz core, 500MHz SDRAM, 6 overvolt) is unstable for my particular Pi. My stress test method is running, dd if=/dev/zero | ssh 192.168.80.5 "dd of=/dev/null", stress --cpu 8 --vm 8 --vm-bytes 20M, and watch -n 1 vcgencmd measure_temp in different screen sessions.

I can do 900MHz ARM, 450 MHz core, 450 MHz SDRAM without overvolting very stably. I switch to performance governor after booting up. I can't use force_turbo, because apparently when my Pi is cold, I can't boot it up with my settings. However the problem disappears when the Pi is warm (around 55-60C). I guess only the God knows why this is the case...

I too used stress in a seperate screen to test stability (18hrs) but anyway. I wonder if your Pi is Hynix or Samsung RAM. It seems to me that 500mhz on RAM is pushing it for nearly every Hynix (especially with no over-voltage for the RAM itself) and is conservative for Samsung. My guess therefore is Hynix and that it is the RAM item that is your limiting factor for that turbo mode? I'm interested either way.

[n1ght28]

I added the temp and CPU frequency widgets to the taskbar but the temp reads -273 C and the CPU 0mhz and governor unknown.

I have tried fast and turbo setting in sudo raspi-config, apt-get is updated and upgraded,

Any ideas what else to try?

[dom]

I added the temp and CPU frequency widgets to the taskbar but the temp reads -273 C and the CPU 0mhz and governor unknown.

I have tried fast and turbo setting in sudo raspi-config, apt-get is updated and upgraded,

Any ideas what else to try?

What does
uname -a
report?
What about:
dmesg |grep cpufreq

[okazou]

Code: Select all

n1ght28 wrote:I added the temp and CPU frequency widgets to the taskbar but the temp reads -273 C and the CPU 0mhz and governor unknown.

I have tried fast and turbo setting in sudo raspi-config, apt-get is updated and upgraded,

Any ideas what else to try?

I had the same problem yesterday. I resolved it by updating de firmware with these commands :

Code: Select all

sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo rpi-update

You need to shutdown and restart after, worked for me!

[edd247]

Code: Select all

cat /proc/cpuinfo |grep Revision
Revision        : 0002

does this mean my warranty is void?

[milhouse]

Code: Select all

cat /proc/cpuinfo |grep Revision
Revision        : 0002

does this mean my warranty is void?

No - if your warranty had been voided it would look like:

Code: Select all

cat /proc/cpuinfo
...
Revision        : 1000002

The right most digit is your particular board revision, 2, 3, 4 etc., and the left-most digit is the "warranty voided" bit - if set to 1, your warranty is toast, if set to 0 it's not.

[edd247]

Code: Select all

cat /proc/cpuinfo |grep Revision
Revision        : 0002

does this mean my warranty is void?

No - if your warranty had been voided it would look like:

Code: Select all

cat /proc/cpuinfo
...
Revision        : 1000002

The right most digit is your particular board revision, 2, 3, 4 etc., and the left-most digit is the "warranty voided" bit - if set to 1, your warranty is toast, if set to 0 it's not.

thanks milhouse, thats what i had thought, just making sure

[jumon]

I've been following the conversations here about the overclock settings. I've updated /boot/config.txt manually and even with raspi-config. I cannot seem to get the board to overclock.

I know it might ramp up and down without forcing it (tried forcing it, too) but not matter what, my freq never goes above 697.95 (even while running a stressful compute and watching the cpu values in another ssh session). I have a rev 3 board. Has overclocking been disabled or something? I've updated to the latest firmware as well in an attempt to ensure I'm current, no luck. Maybe I'm just missing something simple. Please help!

[RaTTuS]

don't look at /proc/cpuinfo as that will only tell you the boot value

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

is what you want

[dms75]

Is there any specific reason for the overcurrent protection to issue a reboot instead of just falling back to the default clock values like the thermal protection does?
I could imagine that it might be a hardware block only capable of doing a reset wich can be disabled, but if it is managed by the firmware first going down to stock values might be a less disruptive measure. Ofc if already running at default clock values a reboot would still be the only possible measure to take

Dirk

[dom]

Is there any specific reason for the overcurrent protection to issue a reboot instead of just falling back to the default clock values like the thermal protection does?
I could imagine that it might be a hardware block only capable of doing a reset wich can be disabled, but if it is managed by the firmware first going down to stock values might be a less disruptive measure. Ofc if already running at default clock values a reboot would still be the only possible measure to take

It's hardware. No control other than switching it off.

[meigrafd]

is it somehow possible to get temperatur and frequency displayed with phpsysinfo ? lm-sensors cant detect it

[nicknml]

It appears that overclocking my pi to 900Mhz has speeded up file transfers a bit. With ftp downloads I can now exceed 8 MB/s