Since launch, we’ve supported overclocking and overvolting your Raspberry Pi by editing config.txt. Overvolting provided more overclocking headroom, but voided your warranty because we were concerned it would decrease the lifetime of the SoC; we set a sticky bit inside BCM2835 to allow us to spot boards which have been overvolted.

We’ve been doing a lot of work to understand the impact of voltage and temperature on lifetime, and are now able to offer a “turbo mode”, which dynamically enables overclock and overvolt under the control of a cpufreq driver, without affecting your warranty. We are happy that the combination of only applying turbo when busy, and limiting turbo when the BCM2835’s internal temperature reaches 85°C, means there will be no measurable reduction in the lifetime of your Raspberry Pi.

You can now choose from one of five overclock presets in raspi-config, the highest of which runs the ARM at 1GHz. The level of stable overclock you can achieve will depend on your specific Pi and on the quality of your power supply; we suggest that Quake 3 is a good stress test for checking if a particular level is completely stable. If you choose too high an overclock, your Pi may fail to boot, in which case holding down the shift key during boot up will disable the overclock for that boot, allowing you to select a lower level.

What does this mean? Comparing the new image with 1GHz turbo enabled, against the previous image at 700MHz, nbench reports 52% faster on integer, 64% faster on floating point and 55% faster on memory.

You can enable a core temperature widget for the lxde taskbar to see how close to 85°C you get (in the UK, it’s not very), and a cpufreq widget that will show the current ARM frequency when you hover over it. See here for more details.

USB interrupt rate reduction

We have enabled Gordon’s “FIQ Fix” in the USB driver, which reduces the USB interrupt rate, improving general performance by about 10%.

WiFi is now supported out of the box

If your WiFi driver is supported by the default linux tree, or is based on the popular RTL8188CUS chipset, then WiFi should work out of the box. Boot the image with the WiFi dongle plugged in (a powered hub is recommended). Run startx and select “WiFi Config”. You can scan for wireless networks and enter your wireless password and connect from the GUI. No need to install additional packages or scripts.

As far as I know, you should use “sudo apt-get update && sudo apt-get dist-upgrade” for upgrading between distributions. You may also need to change your /etc/apt/sources.list first – I’m not exactly sure how the raspberry pi handles this. See “man apt-get” and “www.debian.org” for more info.

Sorry, what I meant to say is the text says quote : “If you are using an older wheezy image, you can upgrade: “sudo apt-get update && sudo apt-get upgrade” will get almost all these improvements.”. So “almost all”, which begs the question; What will be missed out by upgrading as opposed to any other method of getting these features?

I’m not sure if Arch is using the kernel builds from github.com/raspberrypi/firmware or not. If it is, then we build cpufreq in to the kernel. You just need to have something in userspace switch from the “powersave” governor to “ondemand” (we default to powersave to allow for cpufreq to be disabled if you hold down shift during boot, which is something we detect in an init script). Updating to the latest kernel build and adding `echo “ondemand” > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor` to your /etc/rc.local would be sufficient I think.

Yes, a soft float version will go up in the next couple of days. I have updated the firmware packages in the repo, so you actually should be able to follow the first part of the instructions at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=17788 to update your firmware and configure overclock in raspi-config.

Hi Eben, it may not matter in this case but I wonder if it’s worth getting newcomers used to `apt-get dist-upgrade’ rather than plain `upgrade’, it may be more what they need in the general case. Cheers, Ralph.

Many thanks to everybody involved in this achievements. Please, could we have a list of the five overclock presets in raspi-config? Will other distros (like OpenELEC) take advantage of all this speed improvements just upgrading to latest firmware?

Thanks for the info.
The funny thing is that just yesterday I overclocked my PI for the first time ;)
arm_freq=900, core_freq=450, sdram_freq=500, no overvolt
Just tried it with OpenELEC. Everything fine, noticed a big improvement. Are the overclocking settings at config.txt still valid or are they superseded by another method?

Yes they’re valid. raspi-config is just making edits to config.txt for you. Though in recent firmware, without force_turbo=1 (which would set your warranty bit), the settings only take effect when the cpufreq driver switches the clocks. See http://elinux.org/RPi_config.txt#Overclocking_options for more info

Great info thanks. One quick question. From what I’ve read If I want to overclock my PI to 1Ghz then I need add another 6 volts to the existing 5volt supply, thus 11volts? I can not find an 11volt PSU but i can find plenty of 12volt psu’s. Will this 1 extra volt damage to my PI or affecting the warranty?

The GPU core clock is boosted when in turbo mode (and the SDRAM clock) as that improves the ARM performance (it speeds up the ARM’s bus and L2 cache).
We are not currently boosting the 3D and H264 clocks, as they are typically never the bottleneck in the system, and when they are busy is not necessarily correlated with when the ARM is busy, although I’m still experimenting with this behaviour.

Brilliant work!
As far as the temperature goes, I think if you place a home-made small heatsink might do the quick. I remove one from a graphic adapter and cut to size to fit over the RPi chip’s.
Thanks to everyone for your hard work and contributing to the foundation.

With overclocking set to the step below full Turbo, the system is fast and responsive; apart from an initial surge to full CPU loading when opening Midori, the rapid fallback to rippling peaks is impressive (I had spent too much time watching that graph fully blocked,…). The CPU temp monitor is something else to worry about, but at the moment its just tipping 49C so there’s nothing to worry about!

I just bought a colourful USB keyboard to go with the Pibow case and it doesn’t seem to like the increased clockspeed; sometimes keys don’t register, other times a character will start repeatinggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg ;-)

Changing the speed setting from “high” to “modest” seems to have cured this behaviour, so I still benefit from an improved speed though not as much as I would have liked.

Great news! Just curious how much this affects the power used by the device, is it still about 550 mA overall when running hard, or does Turbo Mode cause a significant increase in current draw? (not accounting for anything external)

You might expect the current draw to increase with performance (probably a bit less as there are fixed power costs), so you might expect the power to increase from ~500mA to ~750mA (plus whatever USB devices are connected).

For anyone who was wondering why I posted so vociferously very early on when Pi boards started shipping to use at the very least a 1 amp power adapter, and a 2 amp model would be much better, now you know why. It was not because you would ever reach 2 amps under normal circumstances, but to provide plenty of headroom during power consumption bursts above lower average steady-state current, plus USB device demand (especially now that F2 and F3 are gone on newer boards).

These improvements are all extremely gratefully appreciated by those of us working at the bleeding edge of the board’s capabilities. Now, if only we could have on-the-fly RAM compression/decompression that costs nothing in the way of CPU/GPU performance to effectively expand that 256 MB RAM ceiling … :D

Back in the days of 3/486s there was a MSR called Stacker(if I remember correctly) which claimed to boost your lowly 2/4MB machine to 2x that. It slowed down the system but gave you a pretty constant 25% increase. I’m sure offloading the compression to the GPU it would be smoother than a 4a6 25MHz SX:

I’m currently testing it. Damn, it’s much better (using it with mpd). First, there’s no *click* between the songs, and when starting/stopping it (Although there’s a quiet low frequency boom, but it’s acceptable for me – actually, it reminds me when my turntable raises the pickup on the end of a record). The audo qaulity is also seems much better, but I didn’t do any blind test (I heard the high freq noise on the previous version, now I have to search it with volume/treble settings).
The only (quite little) problem for me is the badly chosed scale for the volume control (it seems linear instead of logarithmical)

It’s because we default to the powersave governor (i.e. no overclock), which allows us to implement the “hold shift to disable overclock” functionality. If you use raspi-config to set an overclock preset once, then an appropriate init script will be generated. Or else add echo “ondemand” > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor to /etc/rc.local

Thanks so much for the continuous and awesome support! I’m so proud to be a Raspberry Pi owner and you guys continue to push the envelope on what these already amazing devices can do. I’ll be ordering many more soon (I am hoping a revision will come out with a power source switch that lets me choose USB or 5v POE).

I think the wiki page for overclocking needs to be edited to say that setting over_voltage more than 6 voids warranty as opposed to setting it more than 0. raspi_config sets over_voltage=6 but this post says that using turbo doesn’t void the warranty?

Is it really a good idea to include more software? Anyone up for developing a piece of software that can bootstrap an SD card from a “recipe” of packages etc rather than having to download 2GB images? We could cut down on bandwidth and it should speed up the write to the SD card a bit too.

Create a small FAT partition (a 32MB FAT16 partition seemed to work for me) and boot it. It’ll take you through an installation process which is similar to a Debian network install. Takes a while (even on a Virgin 30Mbit cable connection) but you can create a minimum base install to add to it (and you can select what optional things you want to install like X, SSH server, file sharing/printing support etc).

I’d guess though going by the date, you would need to manually make the changes to the image or wait until an updated version is released (could be wrong of course, maybe it downloads the updated kernel etc when it downloads the rest of the packages from the Raspbian mirror)

A quick question regarding heat dissipation, in that regard: is there any thermal transfer material to channel the heat from the CPU to the memory chip over it, therefore allowing one to use a heatsink on the memory to cool them both, or is the heat bottled up inside the space under the memory?

Its a package on package device, with a massive amount of interconnects, so there are so many solder balls between the two packages that effectively the thermal resistance between the two packages is very low.

Brilliant, just downloaded the latest kernal and installed an Edimax EW-7811Un wireless adapter, with out a problem. Had been having difficulties before getting it up and running. Thank you guys for all your hard work, it is really appreciated.

Great work on the new image!
I have been using a KVM switch to change between my “office” keyboard and mouse and the Pi but when in the GUI other USB devices and internet stopped working.
All good now.

Why use a KVM? Just run Synergy on your PC and the Pi, and you can move your mouse off the side of your PC screen and onto the Pi screen (and the keyboard input follows it).
See http://synergy-foss.org/

Can we just download the firmware, the three boot files and overwrite existing ones (using OpenELEC RPi) and this will just update the firmware or is this some how specific to a distro or custom compiled kernel?

Fantastic news. It’s great to see all the progress that the Foundation and Broadcom guys (and other volunteers) are making to the Raspi’s software stack :-)
First the armhf build, and now turbo mode… just goes to show how important software optimisation is on low-end hardware.

Tremendous upgrade, thank you all concerned. However, could I be doing something wrong as the Omxplayer no longer seems to want to work, whereas previously it performed faultlessly from the command prompt. I have put the MPEG2 key in the new config.txt, but all I get on trying to play a video is ‘have a nice day’ ! Any thoughts anyone on what is happening? Are there further configurations I need to make?

Really great job guys!!! The performance improved a lot and now I’m not afraid to burn my Pi… I could see a great improvement also using the XBMC installed in my Raspbian, that now is more fluid and it respond fast to the commands! The only real problem that I see is the RAM now, especially if you want to use the XBMC and as I wrote you need to dedicate 128MB of RAM to the video card because you have really too few RAM available and the programs are opening really slowly (and you can’t really surf with Chormium). Is there any possibility to expand in the next version the RAM to at least 512MB (with a small increase of the prize)? I think will make this microcomputer just perfect!

Hm, for me, the turbo mode is slower than overclocking the RPi to 900 MHz overclocking. It seems that the on-demand governor is the problem: Even when compiling AND surfing at the same time, it often keeps 700 MHz and eventually switched to 1000, but then still switches back to 700 often, even though the temperature does is only less than 50 degrees. Will switching to the performance governor void my warranty? Does the performance governor kill a fuse bit? Or can I just use it if it works better for me?

But what if I only want the performance temporarily? For example, when compiling, the ondemand governor sometimes swtiches back to 700 MHz. If I would switch the governor to performance before compilation and back to ondemand afterwards, this can’t happen. But will using the performance governor void my warranty, even if just for a short time?

Nice! This is interesting, because this effectively would be the same as forcing turbo mode, so one would not expect that one voids the warranty and the other does not :). Will it stay this way, or is it possible that with some update suddenly the performance governor will void the warranty?

Boozst! Turbo for the car, turbo for the motorcycle, turbo for ICEs everywhere (Internal combustion engine), turbo for my Intel I7, but best of all Turbo Pi for desert!

Thank you to all for supporting and implementing this feature. The usability and speed is easily 100% better. Now I don’t have to permanently overclock my pi, it “just works”. Best $35 I’ve ever spent. Except that it’s gotten me to spend another $200 on quadcopter parts…. :P

Downloaded the update. Tried to put the image on a SD with my desktop and it seems that my Sony card reader would not work. I have a SD card slot on my Lenovo ThinkPad R500 and using Win32imagewriter I was able to write a SD card that did not update properly on the PI. It worked.
Also I was able to get rid of my ethernet cable as as my RTL8192 dongle worked and i am connected to my home WiFi network.

Turbo is a nice feature, but i wonder if it`s possible to extend it in the opposite direction e.t. a mode i`d call “extended dynamic clocking” to allow for both turbo and deeper power saving when idling at lower than 700Mhz – for example 200Mhz. Useful when someone is just listening an mp3 on battery power.

I tryed to set the overclocking option to TURBO using raspi-config, but it doesn’t boot after reboot, and even worst hold shift doesn’t seem to have any effect, finally I had to put the SD card on another computer and edit config.txt to comment out all the overclocking options.