Overclocking

[dom]

I am testing the kernel and sdhci-bcm2708.cycle_delay=1000
Findings so far (I am guessing these are kind of expected):
http://pastebin.com/kvc50gv0
Have not yet started data corruption testing.

Do the messages in the log go away with a smaller cycle_delay value (e.g. 10).

[Davo7135]

My pi seems completely stable with:

Code: Select all

arm_freq=1100
core_freq=250
sdram_freq=600
over_voltage=6
initial_turbo=60
temp_limit=70

However sdram_freq seems abnormally high with no overvolt, is there a way I check it is set correctly?

If I touch core_freq at all, instant corruption on boot. I could recover it with fsck at 300, but anything higher and I had to completely re-image it. Oh well, running headless with 240mb split so I don't think I'm losing out too much.

Is there any way to programmatically force up into turbo mode? I have a download client that doesn't stay consistently above the turbo threshold and is losing a lot of speed when my pi scales down.

Thanks

[milhouse]

Is there any way to programmatically force up into turbo mode? I have a download client that doesn't stay consistently above the turbo threshold and is losing a lot of speed when my pi scales down.

Thanks

What if you set the governor to "performance" - does it have any effect (can't check myself right now as I'm currently running with force_turbo=1)?

Code: Select all

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

The default is "ondemand".

Tuning the up_threshold (to a lower value, eg. 50 rather than the default 95%) might also work for you (see here for details of how frequency scaling works in other distributions - I'm guessing that much of the same applies to distributions on the Pi)

[Tompen]

I get corruption both with sdhci-bcm2708.cycle_delay=1000 and sdhci-bcm2708.cycle_delay=10
Without core_freq=300 it works ok, so this parameter does not seem to make a difference for me.

It looks like I get the dmesg logging when performance is limited by SD-card. During my data corruption testing I wget a file, then tar -xvf that file. I am performance limited by 20mbit homeplug LAN during wget, and cpu limited during tar -xvf. So I could perform this testing without anything logged in dmesg.

[dom]

I get corruption both with sdhci-bcm2708.cycle_delay=1000 and sdhci-bcm2708.cycle_delay=10
Without core_freq=300 it works ok, so this parameter does not seem to make a difference for me.

It looks like I get the dmesg logging when performance is limited by SD-card. During my data corruption testing I wget a file, then tar -xvf that file. I am performance limited by 20mbit homeplug LAN during wget, and cpu limited during tar -xvf. So I could perform this testing without anything logged in dmesg.

Thanks for testing. Did you try changing dma_wait (mentioned in earlier post).

[shalo]

Code: Select all

sdram_freq=600

However sdram_freq seems abnormally high with no overvolt, is there a way I check it is set correctly?

It has been mentioned a few times in this thread. There is/was a cap on sdram_freq related to the PLL used. I think it is slightly under 600mhz but not certain this has ever been confirmed.

Additionally it is my somewhat confirmed observation that at least some Samsung RAM is rated for 533mhz which would explain why they tend to have no problem hitting the Raspberry PI maximum of ~600mhz.

The Hynix datasheet linked somewhere is more vague and the Pis with Hynix RAM seem to be the ones that require additional sdram voltage to go above ~450mhz.

It could be for many reasons. Speculation given the parties involved is that Samsung are selling these 533mhz parts as 400mhz to satisfy demand. Seems to happen all the time these days, which is hardly news to overclocking enthusiasts.

If your board has Hynix RAM then well, disregard

[Tompen]

Have found one interesting setting that does not seem to cause corruption on SD-card:

current_limit_override=0x5A000020
over_voltage_sdram=6
over_voltage=4
force_turbo=1
arm_freq=1026
sdram_freq=600
core_freq=500
h264_freq=333
isp_freq=333
v3d_freq=333
init_emmc_clock=100000000

I doubled core_freq from 250 to 500, and I also doubled emmc_clock.
This works ok for me (also with xbmc running). But I do not understand why.
Will do more testing...

[dom]

Have found one interesting setting that does not seem to cause corruption on SD-card:
...
I doubled core_freq from 250 to 500, and I also doubled emmc_clock.
This works ok for me (also with xbmc running). But I do not understand why.
Will do more testing...

That's pretty bizarre, but interesting.

What does

Code: Select all

sudo hdparm -t /dev/mmcblk0

give with normal core_freq and emmc, compared to the doubled versions?

[Tompen]

This is with settings from my previous post (the doubled core_freq and emmc_clock).
I have killed xbmc because it reduces the speed when pi is busy.
hdparm -Tt /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 218 MB in 2.00 seconds = 108.80 MB/sec
Timing buffered disk reads: 18 MB in 3.15 seconds = 5.72 MB/sec

below is without overclock core_freq and without overclocked emmc_clock:
/dev/mmcblk0:
Timing cached reads: 202 MB in 2.01 seconds = 100.50 MB/sec
Timing buffered disk reads: 62 MB in 3.06 seconds = 20.24 MB/sec

so it looks like SD-card is running in some corruption-free, low-speed mode.
(have no idea about this stuff)

[dom]

This is with settings from my previous post (the doubled core_freq and emmc_clock).
I have killed xbmc because it reduces the speed when pi is busy.
hdparm -Tt /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 218 MB in 2.00 seconds = 108.80 MB/sec
Timing buffered disk reads: 18 MB in 3.15 seconds = 5.72 MB/sec

below is without overclock core_freq and without overclocked emmc_clock:
/dev/mmcblk0:
Timing cached reads: 202 MB in 2.01 seconds = 100.50 MB/sec
Timing buffered disk reads: 62 MB in 3.06 seconds = 20.24 MB/sec

so it looks like SD-card is running in some corruption-free, low-speed mode.
(have no idea about this stuff)

What about the more logical:
init_emmc_clock=25000000

or even:
init_emmc_clock=12500000

does that avoid the corruption?

I think if the sdcard driver fails to talk to the sdcard initially, it retries with a higher clock divider (i.e. slows down the emmc clock). Perhaps the fix you are seeing is actually from a lower emmc clock.

[Tompen]

Will test with different emmc clock settings as you suggest.
Will also test dma_wait settings (have not tried those yet).

With the doubled clock, vcgencmd measure_clock:
Arm frequency(45)=1026108000
Core frequency(1)=500000000
v3d frequency(43)=333333000
emmc frequency(47)=100000000

without doubled clock, it reports:
Arm frequency(45)=1026108000
Core frequency(1)=250000000
v3d frequency(43)=250000000
emmc frequency(47)=50000000

[portets]

I tried

Code: Select all

init_emmc_clock=100000000

and also didn't get any corruption on multiple tries. A lot of mmc0 errors though. I tried it again with no overclock and received the same errors. After commenting it out, I verified my boot was clean with no errors. I then tried

Code: Select all

init_emmc_clock=25000000

with no overclock, and it corrupted my ext4 with:

Code: Select all

mmc0: Reset 0x2 never completed.
mmc0: Reset 0x4 never completed.
mmc0: Timeout waiting for hardware interrupt - cmd55.

scrolling infinitely. Sometimes "cmd55" is replaced with "cmd-55", "cmd0", "cmd52", and "cmd-52".

[Davo7135]

The default is "ondemand".

Tuning the up_threshold (to a lower value, eg. 50 rather than the default 95%) might also work for you (see here for details of how frequency scaling works in other distributions - I'm guessing that much of the same applies to distributions on the Pi)

This worked a treat, thanks. Set up_threshold to 40, and sampling_down_factor to 10 and it's running a lot better now.

And @shalo, I set sdram_freq to 800 to test if it was being read and my pi didn't even try booting. Revision numbers also indicate Samsung memory so that explains that. Benchmarking against sdram_freq didn't show much difference, not like an overclock to 1.1GHz did. Thanks for your input.

[shalo]

And @shalo, I set sdram_freq to 800 to test if it was being read and my pi didn't even try booting. Revision numbers also indicate Samsung memory so that explains that. Benchmarking against sdram_freq didn't show much difference, not like an overclock to 1.1GHz did. Thanks for your input.

That must be a new logic check? If anyone else is curious, I did those tests away back too. You only really gain performance in synthetic benchmarks with memory clocks and even that it is not that great compared to core_freq.

Hi,
The short version:
Anyone have a way of measuring the effects of raising sdram_freq?

Yes, I use membench. https://github.com/ssvb/ssvb-membench

I've pulled out four columns that show roughly the difference. The fourth in red is actually a different pi with Hynix ram that doesn't easily do whatever the maximum is (it's slightly below 600mhz I believe). At any rate, you can see how much core frequency affects memory bandwidth/latency compared to ram speed.

[milhouse]

https://dl.dropbox.com/u/3669512/temp/kernel_sdcard.img

has a kernel with a new command line parameter:
sdhci-bcm2708.cycle_delay=1000

allows you to get the number of cycles delay between writes to sdcard peripheral registers, in case that is the problem. Please test if it helps.

Does this parameter still work with the latest firmware (new GPU tree etc.)? Just about to try this with 240/16 memory split to see if I can see any difference but I'm now a bit confused about the different firmwares...

[dom]

Does this parameter still work with the latest firmware (new GPU tree etc.)? Just about to try this with 240/16 memory split to see if I can see any difference but I'm now a bit confused about the different firmwares...

Yes, that option is still present.

[milhouse]

Does this parameter still work with the latest firmware (new GPU tree etc.)? Just about to try this with 240/16 memory split to see if I can see any difference but I'm now a bit confused about the different firmwares...

Yes, that option is still present.

OK thanks. So just to be clear, we no longer need the dropbox kernel.img, and can test the new cycle_delay parameter with the kernel installed by rpi-update? Or should we still use the dropbox kernel but with latest rpi-update'd firmware (start.elf etc)? Just that I don't want to waste time testing a parameter that is being ignored...

[dom]

OK thanks. So just to be clear, we no longer need the dropbox kernel.img, and can test the new cycle_delay parameter with the kernel installed by rpi-update? Or should we still use the dropbox kernel but with latest rpi-update'd firmware (start.elf etc)?

The latest rpi-update will have this option. Be aware that the latest rpi-update firmware is somewhat experimental:
http://www.raspberrypi.org/phpBB3/viewt ... 4&p=189178

[milhouse]

Testing various values of cycle_delay and I'm getting catastrophic corruption in Raspbian with the Transcend Class 10 (arm=750/core=255/over_volt=+3). I tested cycle_delays of 10, 100, 1000 and 10000 and every time the same result.

I've been testing with the following firmware:

Code: Select all

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #238 PREEMPT Fri Oct 5 23:19:10 BST 2012 armv6l GNU/Linux

pi@raspberrypi ~ $ vcgencmd version
Oct  6 2012 15:41:08
Copyright (c) 2012 Broadcom
version 342154 (release)

My test procedure is to boot in to Raspbian and perform "dd if=/dev/zero of=./test.dat bs=1M count=500" as user pi - this results in a mass of errors appearing in syslog (pastebin). No quake or anything fancy, just run dd.

I treated myself to a SanDisk Extreme 32GB Class 10/UHS-1 (image below) and this shows different results for the same 750/255/+3 overclock settings - not corruption as such, but the dd test simply never completes (cycle_delay=10/100/1,000/default, but maybe I ran out of patience) or completes veeeery slowly (cycle_delay = 10,000).

This is a picture of the card so you know which one I'm referring to:



The only messages to appear in syslog when performing the dd test with the SanDisk card are the following
(with no cycle_delay in cmdline.txt):

Code: Select all

Oct  6 20:16:50 raspberrypi kernel: [   69.888745] mmc0: final write to SD card still running

(and with cycle_delay=10):

Code: Select all

Oct  6 20:29:02 raspberrypi kernel: [  224.672402] mmc0: Timeout waiting for hardware interrupt - cmd25.
Oct  6 20:29:02 raspberrypi kernel: [  224.672441] mmc0: resetting ongoing cmd 25DMA before 524288/524288 [1]/[1] complete

(and with cycle_delay=10,000, when dd did complete after almost 4 minutes instead of the usual 30 seconds):

Code: Select all

Oct  6 20:55:12 raspberrypi kernel: [   96.028837] mmc0: final write to SD card still running
Oct  6 20:55:22 raspberrypi kernel: [  106.032651] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:55:22 raspberrypi kernel: [  106.033851] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:55:40 raspberrypi kernel: [  123.296837] mmc0: final write to SD card still running
Oct  6 20:55:50 raspberrypi kernel: [  133.312650] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:55:50 raspberrypi kernel: [  133.313874] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:56:07 raspberrypi kernel: [  150.324287] mmc0: final write to SD card still running
Oct  6 20:56:17 raspberrypi kernel: [  160.352653] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:56:17 raspberrypi kernel: [  160.353870] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:56:34 raspberrypi kernel: [  177.405500] mmc0: final write to SD card still running
Oct  6 20:56:44 raspberrypi kernel: [  187.432655] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:56:44 raspberrypi kernel: [  187.433887] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:57:52 raspberrypi kernel: [  255.473948] mmc0: final write to SD card still running
Oct  6 20:58:02 raspberrypi kernel: [  265.492647] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:58:02 raspberrypi kernel: [  265.493852] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:58:44 raspberrypi kernel: [  307.737709] mmc0: final write to SD card still running
Oct  6 20:58:54 raspberrypi kernel: [  317.752645] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:58:54 raspberrypi kernel: [  317.753863] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Oct  6 20:59:11 raspberrypi kernel: [  334.793598] mmc0: final write to SD card still running
Oct  6 20:59:21 raspberrypi kernel: [  344.812649] mmc0: Timeout waiting for hardware interrupt - cmd12.
Oct  6 20:59:21 raspberrypi kernel: [  344.813843] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

With other values of cycle_delay (100 and 1000) there were no messages at all written to syslog.

During the dd test with the SanDisk card, the system becomes unresponsive when executing most new commands (eg. sudo reboot, or starting a new ssh session) - it's as though the Pi is blocked when trying to read or execute the new commands (perhaps blocked when accessing the SD card?)

If I power cycle the Pi during one of these "stuck" dd tests the ext4 filesystem comes up clean on the next boot, however the test.dat file is not present, presumably removed by the fsck during the boot process. The test.dat file is definitely being created - I managed to view it on several occasions prior to power cycling, but it seemed to have become stuck at different points of the file creation process:

Code: Select all

pi@raspberrypi ~ $ ls -la test.dat
-rw-r--r-- 1 pi pi 64065536 Oct  6 20:36 test.dat

and

Code: Select all

pi@raspberrypi ~ $ ls -la test.dat
-rw-r--r-- 1 pi pi 58298368 Oct  6 20:43 test.dat

The only time the dd command completed was with cycle_delay=10,000 - however it completed very slowly:

Code: Select all

dd if=/dev/zero of=./test.dat bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524MB) copied, 239.417 s, 2.2MB/s

The same dd test with settings of 750/250/+3 and cycle_delay=10,000 produces the following results:

Code: Select all

dd if=/dev/zero of=./test2.dat bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524MB) copied, 25.7545 s, 20.4MB/s

and there is no process/command blocking.

Settings of 750/255/+0 are also fine, so it would seem to be over_voltage=+3 in combination with a very slightly overclocked core_freq that is my problem. I have no corruption or blocking problems with either card at 1000/250/500/ov +6/sdram_ov +4. So it's not simply a problem due to over_voltage. Hmmm...

I've got another Pi order on back order... maybe this ones a bit of a lemon. 3 weeks out though (from CPC).

[Badmuts]

Hello All

Is there someone who could explain the turbo mode to, how I can setup it properly? Or where I could find documentation?

Kind regards,
Daan
Big fan from Holland

[Kenji]

Hello,

I had same problem with SD card corruption when overclocking.
I can confirm this settings works well for me (tested with 2 days of intensive using):

Code: Select all

current_limit_override=0x5A000020
over_voltage_sdram=6
over_voltage=6
force_turbo=1
arm_freq=1050
sdram_freq=600

It seems that core_freq overclocking was causing those corruptions.

[wallarug]

Does overvolting the sdram void warrenty still?

[thsBavR10]

Does overvolting the sdram void warrenty still?

dom wrote on 27 Sep 2012 22:33
zeeteex wrote:So is the force_turbo=1 supposed to go into the config.txt file?
Yes, but if used with over_voltage, it will set your "warranty" bit.

[wallarug]

Does overvolting the sdram void warrenty still?

dom wrote on 27 Sep 2012 22:33
zeeteex wrote:So is the force_turbo=1 supposed to go into the config.txt file?
Yes, but if used with over_voltage, it will set your "warranty" bit.

Thanks for the reply.

What is the warranty 'bit'?
I have read people calling it a 'blob'. Is it activated through the temperature getting too high or by someone telling it to do something that it is not allowed to do?
It seemed a little odd to me when we could all of a sudden start over-volting the ARM when we bring in a little software update. I am aware that the voltage and freq are controlled through the cpu_freq module but I just can't understand what exactly sets-off the warranty 'bit'.

[Licaon_Kter]

What is the warranty 'bit'?

basically overvolting triggers it