Overclocking

I take it you are not using the gpu's 3d or h264? 1/3 x 300 and 2/3 x 225 = 250?

Someone smack me if I try to make sense of anyone elses config again.

Woops, selected the wrong button. Maybe someone can delete the duplicate post preceeding.

I just defaulted on everything else. Are there any buidelines about all this?

Jerry

I take it you are not using the gpu's 3d or h264? 1/3 x 300 and 2/3 x 225 = 250?

Someone smack me if I try to make sense of anyone elses config again.

Woops, selected the wrong button. Maybe someone can delete the duplicate post preceeding.

I just defaulted on everything else. Are there any buidelines about all this?

Jerry

There is a thread on overclocking that will explain everything....

No but seriously, just go from page to page of this thread and if you only read dom's posts (possibly some of the context) you'll pick it up.

Do you have no more settings to go with that config? Isn't that running the gpu at a mixture of 211mhz and ~281mhz to average out at the desired 250mhz? If that is really stable might I suggest trying the following instead for what should reap significant benefits in Q3:

core_freq 420
gpu_freq 280

If you've run rpi-update you could just add the new setting for in theory no real net gain but you'll make me happier:

avoid_pwm_pll=1

It's definitely stable - watched Horizon on XBMC with it last night.
Nope, that's all the settings. I've tried the mix of core at 420 and gpu at 280, but any push beyond 250 on the gpu and it falls over. Sometimes immediately, sometimes after a bit of load.

I'll certainly pop avoid_pwm_pll=1 in if you believe it should be there. I'll be honest, in my rush to test I keep forgetting which values have which relationship.

Well, unless someone spots something I have missed you are saying your gpu is perfectly stable while running the gpu at a mix of what equates to 211mhz and ~281mhz. So uhm. Power might be an issue rather than anything else but I'd just suggest learning what the settings do. (I also wouldn't blindly add the avoid_pwm_pll setting because how can you trust me at face value when you aren't sure why I am even suggesting to do it?)

Because I'm a trusting individual with very little to lose.

I built a little spreadsheet to calculate settings valid to pll. I also tells you if they are valid integers.

Code: Select all

Frequencies                                 data
core_freq (input here)                      350
pll_freq                                    700
pll must be equal to or more than 600       TRUE
                                            1/2  1/3    1/4  2/5  3/5
gpu_freqs  gpu(all) or (h264,v3d,isp indv.) 350    233.33 175  280  420
Valid divisors must be integers             TRUE FALSE  TRUE TRUE TRUE


Some of the numbers really may not work like 2/5 and 3/5

What SD cards are you guys using, if using them at all? I tried 3 sd cards with different overclock stability results on raspbian wheezy official 2012-7-15 no updates, upgrades performed. I don't know if drives are factor on overclocks but these are some rough tinkering with observations.

All of them 16GB's. Just booting up and entering lxde. No overvoltage. No change on gpu_freq, sdram_freq
1. pny class 4 premium started to go funny and stopped working around
arm_freq=850-860

2. sandisk class 4 ultra started to go funny and stopped working around
arm_freq=890-900

3. sandisk class 10 ultra started to go funny and stopped working around
arm_freq=930-940

From these disks sandisk class 4 ultra had pretty neat mouse response improvements on
arm_freq=882
gpu_freq=294
sdram_freq=400
This thing actually got pretty usable without much mouse stuttering and midori got better on this setting. Hope someone's current rpi experience improve without overvolting. Cheers

My config.txt has:
arm_freq=900
core_freq=450
sdram_freq=450
which I got out of "Tested Values" in
http://elinux.org/RPi_config.txt
It's an older 2 GB San Disk I had laying around from a camera.

defaulted on everything else except
overscan_top=-16
overscan_bottom=-16
and
framebuffer_width=1366
framebuffer_height=768

I have no idea what the other values default to or how to ask the Pi what they are.

If it's not broken don't fix it.

The 2 GB is getting full I have a 4 GB again old with the 07/15 on it to try next.

Jerry

What SD cards are you guys using, if using them at all? I tried 3 sd cards with different overclock stability results on raspbian wheezy official 2012-7-15 no updates, upgrades performed. I don't know if drives are factor on overclocks but these are some rough tinkering with observations.

All of them 16GB's. Just booting up and entering lxde. No overvoltage. No change on gpu_freq, sdram_freq
1. pny class 4 premium started to go funny and stopped working around
arm_freq=850-860

2. sandisk class 4 ultra started to go funny and stopped working around
arm_freq=890-900

3. sandisk class 10 ultra started to go funny and stopped working around
arm_freq=930-940

From these disks sandisk class 4 ultra had pretty neat mouse response improvements on
arm_freq=882
gpu_freq=294
sdram_freq=400
This thing actually got pretty usable without much mouse stuttering and midori got better on this setting. Hope someone's current rpi experience improve without overvolting. Cheers

I don't understand this but I saw broadly the same thing, especially when I added some over-voltage. With a 4gb Sandisk class 4 card I saw some corruption twice on the ext4 partition around ~925mhz+. When I moved the OS to a usb disk it was fine up to 1100mhz with 1150 causing a crash but no corruption.

Something else I have noticed is that it seems pretty certain that for whatever (bonus) reason, at least some of the Raspberry Pis with Samsung RAM have the stuff rated for 533mhz. As mentioned there seems to be a cap due to the pll and I reckon it is around 575mhz. There is no problem hitting the cap for these boards with stock sdram voltage. It explains why some boards are hitting this cap and others get to around 450mhz or maybe around 500mhz, sometimes requiring a little over-volt even but there's no boards really inbetween.

I originally wrote this program for my own overclocking purposes, but it does much more than that now, it's still work in progress, so any input on how to improve or add to it, let me know....

viewtopic.php?f=48&t=14021

What SD cards are you guys using, if using them at all? I tried 3 sd cards with different overclock stability results on raspbian wheezy official 2012-7-15 no updates, upgrades performed. I don't know if drives are factor on overclocks but these are some rough tinkering with observations.

All of them 16GB's. Just booting up and entering lxde. No overvoltage. No change on gpu_freq, sdram_freq
1. pny class 4 premium started to go funny and stopped working around
arm_freq=850-860

2. sandisk class 4 ultra started to go funny and stopped working around
arm_freq=890-900

3. sandisk class 10 ultra started to go funny and stopped working around
arm_freq=930-940

From these disks sandisk class 4 ultra had pretty neat mouse response improvements on
arm_freq=882
gpu_freq=294
sdram_freq=400
This thing actually got pretty usable without much mouse stuttering and midori got better on this setting. Hope someone's current rpi experience improve without overvolting. Cheers

I don't understand this but I saw broadly the same thing, especially when I added some over-voltage. With a 4gb Sandisk class 4 card I saw some corruption twice on the ext4 partition around ~925mhz+. When I moved the OS to a usb disk it was fine up to 1100mhz with 1150 causing a crash but no corruption.

Something else I have noticed is that it seems pretty certain that for whatever (bonus) reason, at least some of the Raspberry Pis with Samsung RAM have the stuff rated for 533mhz. As mentioned there seems to be a cap due to the pll and I reckon it is around 575mhz. There is no problem hitting the cap for these boards with stock sdram voltage. It explains why some boards are hitting this cap and others get to around 450mhz or maybe around 500mhz, sometimes requiring a little over-volt even but there's no boards really inbetween.

I tried with usb drive and raspbian installer rpi-update and 1ghz was easily achieved. I touched the cpu/ram chip at 1ghz and it was hot. on around 900mhz it was just warm but 1ghz gave me a little burning feeling on my finger

Soooo, "Allow PWM PLL to be repurposed for H264/ISP/V3D."

I guess this might be a way to unlink H264/ISP/V3D from core_freq?

Yes,
avoid_pwm_pll=1

in config.txt. The PWM PLL will be freed up (anlogue audio should still work, but from a fractional divider, so lower quality).

H264/ISP/V3D are tied together, but now are unrelated to GPU core freq. So this is valid:
gpu_freq=320
core_freq=450

There is something wrong with this and there is a difference on the most recent firmware. It's not really overclocking per se but since the setting relates to overclocking and this is the only real reference to it, I will put my observations all using the 128/128 splits, here:

Previous firmware:
config is pretty much default, just adding avoid_pwm_pll=1
a) Q3 runs fine, audio quality from analogue slightly diminished.
b) xbmc crashes when watching a video: with analogue audio chosen, with hdmi audio chosen, video with no audio track.

Newest firmware:
config: again just adding avoid_pwn_pll=1
a) Q3 still runs but now audio quality from analogue is terrible. Very loud hiss and usual ingame sounds are barely audible.
b) xbmc crashes when watching an h264 video with audio, crashes when watching h264 with no audio. However, after an initial audio screech a wmv I had with only the audio track available (video codec not supported) eventually plays ok with a hiss expected of the diminished quality. The quality is comparable to q3 on the previous firmware, but much better than q3 on this firmware.

Newest firmware:
config has avoid_pwn_pll=1 and what should be superfluous, core_freq=250, gpu_freq=250
a)/b) same as the previous test.

Newest firmware:
config as previous but also adding what ought to be superfluous h264_freq=250
b) wmv with just audio as before. I was able to launch a known to work h264 video file, audio started to play, screen was black however and xbmc crashed after maybe ~20secs. In all previous tests this file crashed right before it should start to play.

Nearly all of the xbmc crashes still allowed me to SSH to the pi, usually the display would be locked up on return but occasionally the terminal came back after killing the hanging xbmc process. With the previous firmware (that introduced the setting) I was unable to SSH in after a lockup playing the h264 file with no audio track twice.

I guess in summary that there are two issues here. The audio dropoff between the two firmwares and also some issue with the h264 block when using avoid_pwn_pll=1 that is the same on both these two firmwares.

[dom]

@shalo

Can you confirm with:
/opt/vc/bin/vcgenmd version

exactly what the two firmwares you are referring to. Ideally they will be consecutive firmware versions from github, so I can look through a small set of source changes to get some idea of the problem.

@shalo

Can you confirm with:
/opt/vc/bin/vcgenmd version

exactly what the two firmwares you are referring to. Ideally they will be consecutive firmware versions from github, so I can look through a small set of source changes to get some idea of the problem.

vcgencmd for what I referred to as newest shows:
Aug 8 2012 22:55:02
Copyright (c) 2012 Broadcom
version 330232 (release)

I suspect the other firmware was:
Aug 1 2012 19:48:24
Copyright (c) 2012 Broadcom
version 328870 (release)

I've just taken these details from a 240mb split on a different pi that is still running the "previous" set of firmware I was talking about. Obviously I was using the 128mb split and assume they share version numbers.

[dom]

vcgencmd for what I referred to as newest shows:
Aug 8 2012 22:55:02
Copyright (c) 2012 Broadcom
version 330232 (release)

I suspect the other firmware was:
Aug 1 2012 19:48:24
Copyright (c) 2012 Broadcom
version 328870 (release)

I've just taken these details from a 240mb split on a different pi that is still running the "previous" set of firmware I was talking about. Obviously I was using the 128mb split and assume they share version numbers.

There are 3 other firmware updates in between those two. Can you narrow it down?
I'd imagine only the start.elf file is relevant.

You can download a specific version of start.elf from github:
https://github.com/raspberrypi/firmware ... f?raw=true
(or use git directly).

vcgencmd for what I referred to as newest shows:
Aug 8 2012 22:55:02
Copyright (c) 2012 Broadcom
version 330232 (release)

I suspect the other firmware was:
Aug 1 2012 19:48:24
Copyright (c) 2012 Broadcom
version 328870 (release)

I've just taken these details from a 240mb split on a different pi that is still running the "previous" set of firmware I was talking about. Obviously I was using the 128mb split and assume they share version numbers.

There are 3 other firmware updates in between those two. Can you narrow it down?
I'd imagine only the start.elf file is relevant.

You can download a specific version of start.elf from github:
https://github.com/raspberrypi/firmware ... f?raw=true
(or use git directly).

Ok this is my bad. I tried the firmware and they showed the same problems. The audio is an issue with the newer module, the three day old snd-bcm2835.ko in combination with avoid_pwm_pll has seemingly introduced it, from a quick test.

The h264 issue seems to exist on all firmware that has the option of avoid_pwm_pll and when using that option set to 1, no matter what the core/gpu/h264 block is set to or not set to.

Decided the time had come to ramp up my Pi speed, came to the conclusion that over_voltage_sdram is useful but little mentioned in this thread.

I had been running a plain arm_freq=850 since about day 2 and headed straight for "Dom's settings"
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
which hung after a few minutes in midori. Ramping over_voltage=8 didn't help, so added over_voltage_sdram=4 which stabilised things (FWIW I have Hynix memory). Backing over_voltage=4 gave some Bad IRQ75 in dmesg, setting back to over_voltage=6 cleared that.
Don't claim to have a rock solid overclock as have done limited stress testing but what I currently have and seems OK so far is

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4

Poking around some slow Midori response I'm using 900/450/450 overclock, seemed to me that memory size might be a cram at 192/64 split. I haven't tried 224/32 since I don't know how much memory the GPU is using for 1366/768 resolution. No clue when if ever there'll be a Pi with more memory. There are a couple other boards out there so far none of them can touch the Pi forums.

On booting I'd opted for expanding root to end of 4G. Then I noticed debian's using a swapfile not a swap partition. Took the SD to a notebook, made a swap partition of 2x192 or 384 MB.

Booted that, didn't understand cat /proc/meminfo at 524 MB? so edited /etc/fstab to recognize the swap partition at boot, rebooted, then turned the swap file off since swap partitions are supposed to be faster.

My impression is Midori response a little faster. So there are other ways to improve Raspian speed than overvolt. I do wonder how much advantage Debian is taking of the GPU capability. That's way beyond me.

Jerry

[dom]

Poking around some slow Midori response I'm using 900/450/450 overclock, seemed to me that memory size might be a cram at 192/64 split. I haven't tried 224/32 since I don't know how much memory the GPU is using for 1366/768 resolution. No clue when if ever there'll be a Pi with more memory. There are a couple other boards out there so far none of them can touch the Pi forums.

If you are not using 3D or HW decoded video, then any split is fine. If you use latest firmware you can use a 240M split, which should make LXDE quite a bit smoother.

[dom]

Ok this is my bad. I tried the firmware and they showed the same problems. The audio is an issue with the newer module, the three day old snd-bcm2835.ko in combination with avoid_pwm_pll has seemingly introduced it, from a quick test.
The h264 issue seems to exist on all firmware that has the option of avoid_pwm_pll and when using that option set to 1, no matter what the core/gpu/h264 block is set to or not set to.

Yes, I can see the H264 + avoid_pwm_pll lock up. I need to check with hardware guys if there's a restriction on h264 block I'm not aware of. Strange that 3D hardware seems okay with avoid_pwm_pll.

So are you saying an update to snd-bcm2835.ko made audio quality worse when avoid_pwm_pll is enabled?
Can you point at the git commit for kernel (or uname -a version) that introduced the degredation?

So are you saying an update to snd-bcm2835.ko made audio quality worse when avoid_pwm_pll is enabled?
Can you point at the git commit for kernel (or uname -a version) that introduced the degredation?

It's hard to be precise. I would say the sound in xbmc is the same with both kernels, though given the h264 situation the only file I had to test was uh a wmv video file that only played back the WMA v2 audio track.

Quake3 though with the current module and avoid_pwn_pll...the audio is basically unusable. There is an overall static. The game sounds are barely audible behind it.

I only played around with the .ko file where I found copying the old one back, made the sound work in Q3 again. Copying back the current one caused it to sound corrupted again. I can only see recent entries on 1st Aug (#242) and 7th Aug (#272) in the github, so it should be between those two. I don't really know what I'm doing, I didn't really think just copying the .ko file would do anything other than complain about version matches

[dom]

I didn't really think just copying the .ko file would do anything other than complain about version matches

Yes, you should grab the kernel.img and snd-bcm2835.ko from the same git commit to avoid version mismatches.

I didn't really think just copying the .ko file would do anything other than complain about version matches

Yes, you should grab the kernel.img and snd-bcm2835.ko from the same git commit to avoid version mismatches.

Sure, but to clarify the difference originally arose with the two kernels with their respective correct modules I was just throwing in an extra test so see what would happen.

I was only really exploring the avoid_pwm_pll because of some odd results with one of my RPis. I think I need to understand the relationship between the 1.2v rail for the SOC and psu quality a little more, I seem to recall reading about the way the rails are generated on the board somewhere so I'm sure I can find it again.

That stuff about the avoid_pwm_pll 1 and quake3 audio is wrong.

Analogue (don't know about hdmi) audio doesn't work at all for me with Q3 and the newest kernel/modules from rpi-update.

Copying over the old .ko works but it seems like it's because the boot process is doing some sort of fallback. During the boot process it appears to load the module fine, with a few confirmations but much later in the boot process is this message:

Setting up ALSA_warning: "alsactl restore" failed with error message, "found hardware:" "brcm bcm2835 AL" "broadcom mixer" "" "" "" Hardware is initialized using generic method. This generic method plays the Q3 audio just fine...

At any rate, this is an issue with my Q3 and the newest kernels and not avoid_pwm_pll. I'll try rebuilding Q3 later or something, this is definitely the wrong thread for it now.

Decided the time had come to ramp up my Pi speed, came to the conclusion that over_voltage_sdram is useful but little mentioned in this thread.

I had been running a plain arm_freq=850 since about day 2 and headed straight for "Dom's settings"
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
which hung after a few minutes in midori. Ramping over_voltage=8 didn't help, so added over_voltage_sdram=4 which stabilised things (FWIW I have Hynix memory). Backing over_voltage=4 gave some Bad IRQ75 in dmesg, setting back to over_voltage=6 cleared that.
Don't claim to have a rock solid overclock as have done limited stress testing but what I currently have and seems OK so far is

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4

I'm using this now:
arm_freq=1000
core_freq=500
sdram_freq=525
over_voltage=6
over_voltage_sdram=5

I had even higher settings but the Pi got very hot and didn't pass the "crash test" - one day playing music in repeat (which keeps the CPU at between 30 to 50% utilization).

[dom]

The h264 issue seems to exist on all firmware that has the option of avoid_pwm_pll and when using that option set to 1, no matter what the core/gpu/h264 block is set to or not set to.

I've spoken to clocks guy, and think I've got a fix for avoid_pwm_pll + H264. Try after an rpi-update.

The h264 issue seems to exist on all firmware that has the option of avoid_pwm_pll and when using that option set to 1, no matter what the core/gpu/h264 block is set to or not set to.

I've spoken to clocks guy, and think I've got a fix for avoid_pwm_pll + H264. Try after an rpi-update.

Seems to work....however, I think core_freq (and gpu_freq) is broken or has been changed now in some way. Basically core_freq=500 is showing the same results as 250 to me.

I've not tested extensively but tried the following tests, which all show the same performance levels:

1. core_freq=500
2. core_freq=500 and gpu_freq=250
3. default
4. core_freq=500 and avoid_pwm_pll=1
5. gpu_freq=500 and avoid_pwm_pll=1

Obviously not even tried to use h264/3d block with test #5 but it will probably work since the setting hasn't taken hold (I'd be able to tell performance from a core value of 500).

ARM CPU overclocking setting is still working so it's not some new failsafe in config.

To confirm, vcgencmd, confirmed observations on 128/128 and 240/16 splits:

Aug 17 2012 16:57:51
Copyright (c) 2012 Broadcom
version 331989 (release)

Reverting to prior firmware resolves the core_freq overclocking setting (It gets lost at times so I'll throw in a thanks for all the work and effort that you guys are doing).