User avatar
hojnikb
Posts: 128
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home

Re: Overclocking

Thu Sep 27, 2012 9:59 pm

milhouse wrote:
dom wrote: Sounds reasonable. It's on my list.
Many thanks in advance! :)
Great. Now i will be able to squeeze magical 1.2Ghz from my Pi without actually running at this freq all the time :D

As for the sdcard curruption; today when i OC it to 1.1Ghz to compile something, when i made apt-get, some of the files linked with apt got currupted (never happend before when was on 930 with no overvolt).Thankfully files could be easily replaced, so it was not a big deal.
edit:
this was with raspbian default repo kernel/fw, not the latest one from rpi-update

So if i get this currupion thing correctly: when Pi is overclocked, becouse arm freq is changed and some timing is different, this somehow messes acces to sd card, is that correct ?

Could the issue be in the sdcard driver itself or is that not the problem (afaik driver was the issue back then when cards were really slow) ?
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Thu Sep 27, 2012 10:11 pm

@dom - I use a simple script (which you can see here) that runs every few seconds, and displays various outputs from vcgencmd such as current ARM/Core/H264 frequency, Core Temp etc. - ie. the vcgencmd command is executed a large number of times during any given period - so my question is: is there any way this vcgencmd activity could interfere with the operation of the arm or core etc., and result in some sort of corruption? I'm pretty sure the answer is "no", but just wanted to check...

I've struggled to identify any correlation between corruption/instability and the running of this script (which I've left to run for over 24 hours without any problem) but the merest possibility of it existing is starting to prey on my mind!

User avatar
Licaon_Kter
Posts: 240
Joined: Wed Sep 05, 2012 10:12 am
Location: Between the keyboard and the chair.

Re: Overclocking

Thu Sep 27, 2012 10:20 pm

dom wrote:...
Possibly some Pi boards (specifically the 2835 SoC) are not succeptable to this problem.
...
Don't they all have the same SoC anyway?

BTW, I've have been using:

Code: Select all

arm:850
core:450
v3d/isp/h264:300
sdram:450
no overvolt
BUT NEVER getting a corrupted card, and even when trying some OC options that lock/restart the Pi like sdram >450 or arm>850 everything was in place after a restart.Was I just lucky? ( this card: http://www.raspberrypi.org/phpBB3/viewt ... 24#p166624 )

Here is my OC procedure:
*use the 192/64 mem split
*edit config.txt with your OC values of choice
*reboot
*get my q3 demos: http://www.sendspace.com/file/i91m1o and put them both in /home/pi/.q3a/baseq3/demos/ ( if the game does not see them maybe you need to put them in /root/.q3a/baseq3/demos/ too )
*start quake3
*console -> timedemo 1
*demo dema-1, wait for it to finish (<120sec), if it has not crashed, continue
*demo dema-2, wait for it to finish (<360sec), if it has not crashed, continue

looks ok, BUT, here's the thing, try something else
*quit quake3
*open TTY2, run stress --cpu 1 --vm 2 --vm-bytes 32M ( run sudo apt-get install stress if you don't have this program ) this will stress the CPU/MEM in the background but will leave the flimsy SD card alone
*switch back to TTY1 and run quake3
*console -> timedemo 1
*demo dema-1, wait for it to finish (more than 120sec), if it has not crashed, continue
*demo dema-2, wait for it to finish (more than 360sec), if it has not crashed, you might be ok
*quit quake3
*switch back to TTY2 and hit CTRL+C to stop stress
*repeat from start with bigger OC values

If you are still running ok after passing these I believe you got a good OC, in my testing it happened numerous times, I could pass the normal demos, or even lower, pass demo1, but not demo2, or pass both and crash when using stress at the same time, so while pushing 1GHz in TTY1 looks like a good OC if you did not pass these quake3 tests I believe it's just a disaster waiting to happen the next time your system gets a bit of work to do.

A bit of info on the demos:
*yes it's me playing after I got quake3 compiled, I'm rusty
*yes they're made in the DEMO version ( do PM me if you want to upload my build if you don't have it )
*I had to record them as the so called "four" demo never run on my system
*yes I misspelled the names to DEMA-1/2 and use them like that
*the first one has me and 3 other bots, it will use a lot of CPU at ~27fps average for the non-OC freqs (1920x1200, all high, 32bit framebuffer)
*the second one has me and 1 other bot, it will do a lot of fps ~38fps (1920x1200, all high, 32bit framebuffer) average for the non-OC freqs, there's a moment of seemingly pause as I fiddle with my controls, do wait, it ends at 9-3 for the bot, look in the lower right corner for the score, surprisingly this map was crashing ON LOAD when using some OC values that were passing the first demo with ease, and this got me thinking
Last edited by Licaon_Kter on Thu Sep 27, 2012 10:27 pm, edited 1 time in total.
BFQ+BFS or RT on a RPi? 4'real: https://github.com/licaon-kter/ (source and compiled!)

Dilligaf
Posts: 283
Joined: Wed May 23, 2012 6:48 pm

Re: Overclocking

Thu Sep 27, 2012 10:26 pm

Yeah, but the quake 3 demos and stress don't do many writes to the card, I think it's multiple writes that are causing the issues. With xbmc I can do whatever in it and have no problems, do a library scan and it corrupts the card

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Thu Sep 27, 2012 10:31 pm

milhouse wrote: I've struggled to identify any correlation between corruption/instability and the running of this script (which I've left to run for over 24 hours without any problem) but the merest possibility of it existing is starting to prey on my mind!
Hmmmm. It's unlikely but not inconceivable. It could be worth disabling and see if anything behaves better.

User avatar
Licaon_Kter
Posts: 240
Joined: Wed Sep 05, 2012 10:12 am
Location: Between the keyboard and the chair.

Re: Overclocking

Thu Sep 27, 2012 10:32 pm

Dilligaf wrote:Yeah, but the quake 3 demos and stress don't do many writes to the card, I think it's multiple writes that are causing the issues. With xbmc I can do whatever in it and have no problems, do a library scan and it corrupts the card
Yes and no, before trying to asses the influence on the SD card part of the Pi shouldn't you assure a proper tested stable OC?
Having an unstable OC would yield all sorts of problems... exactly, just because XBMC might not load the Pi (both CPU and MEM wise) enough to expose such instability it does not mean it's not there, and when it tries to access the card, allocate buffers, whatever... bang... instability... corruption etc

BTW, stress has IO options too if that strikes your fancy, I did not use them as the SD cards are the weakest link in the hardware chain (expensive and fragile).
BFQ+BFS or RT on a RPi? 4'real: https://github.com/licaon-kter/ (source and compiled!)

kevs3d
Posts: 23
Joined: Fri Sep 07, 2012 6:26 pm

Re: Overclocking

Fri Sep 28, 2012 8:25 am

Hi, I've done quite a bit of testing with this last night. And for me - It's ALL about core frequency.

I can run reliably with my Transcend class 10 card with these settings:

Code: Select all

force_turbo=1
current_limit_override=0x5A000020
over_voltage=8
arm_freq=1100
sdram_freq=400
core_freq=250
Perform the usual CPU stress tests, quake3 and card writes - no issues.

As soon as I raise the core freq it all gets a bit wobbly - /boot corruption and/or kernel fail to init on startup.

Even core 300 is enough for it to get into a corrupted state.

With the class 4 card (Kingston) this does not happen - I can run core 500 with those same settings above.

For my setup certainly, this makes me confident the core settings are causing the problems - obviously since that's tied to so much other stuff, I'm not sure how much it helps :)

I will try keeping [email protected] next and raise the core just by itself to see if that can corrupt it also.

Cheers,

Kev
--
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.

Tompen
Posts: 20
Joined: Tue Aug 14, 2012 4:11 pm

Re: Overclocking

Fri Sep 28, 2012 12:35 pm

Found a backup of my working xbian install from 9 sep, restored to this SD-card. Same problem, corruption with core_freq=300 and also with core_freq=310. Will try lots of older start.elf and kernels to understand if I can find any combination that works.

sumolx
Posts: 4
Joined: Fri Sep 28, 2012 3:07 pm

Re: Overclocking

Fri Sep 28, 2012 3:30 pm

My setup:

Code: Select all

SD Card:  SanDisk videoHD 8 GByte Class 4 Card
Image:    r12014.img.zip	27-Sep-2012 15:02	 83M
Rock solid with the following:

Code: Select all

boot_delay=1
force_turbo=1
over_voltage=4
arm_freq=900
gpu_freq=333
core_freq=500
sdram_freq=500
Now if I increase over_voltage=6 then the EXT4 partition becomes corrupted. I was increasing the voltage in order to achieve a stable arm_freq=1000. I had then reverted back to my original setting arm_freq=900 but I forgot to revert over_voltage=4, finding this would cause corruption. So I'm staying away from over_voltage=6 for now.

On a side note I am back-feeding Apple's 1 amp iPhone power supply to the lower USB port with using an A to A cable. This guarantees a 4.85v across TP1 and TP2 with Ethernet plugged in. Using the same power supply and trying many different Micro USB cables I could only achieve 4.20v ~ 4.35v which would cause all sorts of havoc.

kevs3d
Posts: 23
Joined: Fri Sep 07, 2012 6:26 pm

Re: Overclocking

Fri Sep 28, 2012 4:15 pm

Just a confirmation from further testing with these values:

Code: Select all

arm_freq=1100
core_freq=250
gpu_freq=333
sdram_freq=400
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020
Rock solid in all tests for me - including a full apt-get update/upgrade + rpi-update (which always killed it before!) Raise core to 300 and BOOM - corruption almost immediately.

And with these settings, note only the core is overclocked - will corrupt the card (seems ok with core<500 with default arm speed)

Code: Select all

arm_freq=700
core_freq=500
So I'm going with raising core_freq as the definitive killer for my class 10 card!

Is there any way to disconnect the arm caches and SD card timings from the core? i.e. so we can still overclock the caches (which makes a big difference on many tests, including quake3) - but leave the SD card out of the fun? Yep, I have no idea what I'm talking about :lol: but I'm at least happy I can overclock to ARM 1100Mhz and GPU 333Mhz as long as I leave the core alone!

Kev
--
http://www.kevs3d.co.uk/dev - HTML5 canvas games, demos and utils.

Tompen
Posts: 20
Joined: Tue Aug 14, 2012 4:11 pm

Re: Overclocking

Fri Sep 28, 2012 4:48 pm

I can consistenly reproduce data corruption with core_freq=300.
Without core_freq=300 it works OK. Because it is easy for me to do, I made some test.

I did the below tests 3 times, with identical result.

Booted wihout overclocked core_freq, wget my 88MB testfile.
change to core_freq=300 and reboot, then tar -xvf the file I had download. It works ok. Integrity of files written is questionable. My point is, it reads the file OK, tar -xvf does not detect corruption.

My other test:
Booted without overclocking core_freq. wget my 88MB testfile, twice. Reboot. Diff the downloaded files, no difference (as expected). Change to core_freq=300, reboot. diff the files, no difference. This is proof data is not getting corrupted during reads from SD-card.

While overclocked, transfer these two files to a ftp server. On ftp server, I diff the files. no difference.
This is proof data does not corrupt while being read from SD-card. It is proof data does not corrupt while transfer on LAN.

while overclocked, copy the file. Then reboot (to empty filecache in RAM).
diff the orginal file with the copied file. They differ.
This is proof data gets corrupted when it is being written to SD-card.

Tompen
Posts: 20
Joined: Tue Aug 14, 2012 4:11 pm

Re: Overclocking

Fri Sep 28, 2012 7:22 pm

A progress report from my testing

This works, I do not get corruption with core_freq=300 (all other settings kept the same, maybe my config.txt options do not exist in this older release, but I just keep them anyway)

works OK:
commit 43b688a2
Add sync_after_dma module parameter to kernel.
[email protected]:~# uname -a
Linux XBian 3.1.9+ #171 PREEMPT Tue Jul 17 01:08:22 BST 2012 armv6l GNU/Linux
[email protected]:~# /opt/vc/bin/vcgencmd version
Jul 17 2012 01:25:40
Copyright (c) 2012 Broadcom
version 325699 (release)

and to be certain, I tested also 8e981b6b and it also works without corruption in my test.

But the below and newer does not work, I get corruption with core_freq=300:
0d88fba0
Date: Thu Jul 26 00:50:08 2012 +0100
Trim the firmware builds. Add a smaller arm240_start.elf
[email protected]:~# uname -a
Linux XBian 3.1.9+ #202 PREEMPT Wed Jul 25 22:11:06 BST 2012 armv6l GNU/Linux
[email protected]:~# /opt/vc/bin/vcgencmd version
Jul 26 2012 00:48:29
Copyright (c) 2012 Broadcom
version 327550 (release)

I have no way of verifying that core_freq=300 actually sets something in the july releases because
vcgencmd measure_clock core
does not exist.

I will continue to reduce the scope, narrow it down further.
When I am certain, I will post here again. I have only tested once for the commits I have tried so far. But since my corruption does not seem intermittent, I hope the above is accurate.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Fri Sep 28, 2012 7:31 pm

Tompen wrote:I will continue to reduce the scope, narrow it down further.
When I am certain, I will post here again. I have only tested once for the commits I have tried so far. But since my corruption does not seem intermittent, I hope the above is accurate.
This is useful. If you can confirm a single file change by a single revision, then I can hopefully identify the change. I'm assuming it is just start.elf that matters, not kernel.img.
Does that tie up with what you are seeing?

Tompen
Posts: 20
Joined: Tue Aug 14, 2012 4:11 pm

Re: Overclocking

Fri Sep 28, 2012 8:22 pm

Yes, I understand. Have not tried single file replace, I am replacing all files in /boot except cmdline.txt and config.txt. My goal is to find the revision that breaks it (hopefully). Then I will try isolate to single file (hopefully). But from past experience, data corruption is very elusive to figure out. Have been doing the same on other product a few years ago, and thought I was on the right track, but then realised I was wrong. A few days later I thought I was on another track that was right, and at that time I found it. Nothing is certain until it is certain.... It needs a lot of patience and even more testing.

pmk
Posts: 21
Joined: Wed Jun 20, 2012 5:27 pm

Re: Overclocking

Fri Sep 28, 2012 8:30 pm

Tompen wrote:Yes, I understand. Have not tried single file replace, I am replacing all files in /boot except cmdline.txt and config.txt. My goal is to find the revision that breaks it (hopefully). Then I will try isolate to single file (hopefully). But from past experience, data corruption is very elusive to figure out. Have been doing the same on other product a few years ago, and thought I was on the right track, but then realised I was wrong. A few days later I thought I was on another track that was right, and at that time I found it. Nothing is certain until it is certain.... It needs a lot of patience and even more testing.
If you can provide the files and a procedure I am free to do some testing on Sunday .......

Kekule
Posts: 2
Joined: Fri Sep 28, 2012 10:33 pm

Re: Overclocking

Fri Sep 28, 2012 10:35 pm

I could be way off base, but from my understanding the core_freq configuration effects the L2 cache frequency. Could this all be related to some issue with the cache?

sumolx
Posts: 4
Joined: Fri Sep 28, 2012 3:07 pm

Re: Overclocking

Sat Sep 29, 2012 4:00 am

Ok.. I have been experimenting some more and I am able to achieve a rock solid overclock with the following settings. Viewing XBMC System -> Status -> Video or Hardware: My temp reached 83C

Code: Select all

arm_freq=1000
gpu_freq=333
core_freq=500
sdram_freq=500
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020
Now i was able to corrupt my card by forcing these additional settings:

Code: Select all

h264_freq=333
isp_freq=333
v3d_freq=333
I'm thinking it's not v3d_freq=333 due to the reason I was seeing this clock speed being enforced with only gpu_freq=333 being specified. I was measuring v3d by using command: "vcgencmd measure_clock v3d" and it would report 333.

However, h264 and isp always reported 250 during playback of a sample mkv and thats why I decided to try and enforce those values manually. At that point my card became corrupt during boot up.

Quick question with my settings if I hit 85C with force_turbo=1 will it automatically down clock arm, gpu and core until the temps are safe again?

Twigs
Posts: 1
Joined: Sat Sep 29, 2012 3:20 am

Re: Overclocking

Sat Sep 29, 2012 4:08 am

some testing on my pi;
I can do
arm_freq=1000, core_freq=500, sdram_freq=500, over_voltage=4 with no issues
however
arm_freq=1000, core_freq=500, sdram_freq=500, over_voltage=6 causes final write errors and corruption - too much over voltage?

or

If i leave out the core_freq, I can wind it up to
arm_freq=1200, sdram_freq=600, over_voltage=12, over_voltage_sdram=4 with no issues
however
arm_freq=1200, sdram_freq=600, over_voltage=12, over_voltage_sdram=4, core_freq=400 causes final write errors and corruption.

The only way for me to get the core_freq higher than default is to start winding back arm_freq and voltages. It feels like there is a finite amount of "power" and that i can push it all to the arm and sdram or share some with the core. Is there any chance that there is literally a drop in voltage when pushing the overclock limits that is starving the sd card of power?

class 4 8GB sd card
Powered from psp charger hooked to gpio pins
voltage at the 5v power capacitor;
Idle 5.02v
100% cpu 5.00v (running "openssl speed")
never seen it below 4.99v
cpu is cooled and has never gotten above 46c
force_turbo=1
current_limit_override=0x5A000020

I will try testing some 3.3v traces tomorrow.
good night :D

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Sat Sep 29, 2012 9:00 am

sumolx wrote: Now i was able to corrupt my card by forcing these additional settings:

Code: Select all

h264_freq=333
isp_freq=333
v3d_freq=333
I'll check the code, but those settings should have no effect (gpu_freq already did that)
Quick question with my settings if I hit 85C with force_turbo=1 will it automatically down clock arm, gpu and core until the temps are safe again?
Yes

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Sat Sep 29, 2012 9:03 am

Twigs wrote: I will try testing some 3.3v traces tomorrow.
good night :D
It could be a voltage drop, but I would have expected that to be seen that on the 5V rail.
3.3V is used for the sdcard I/O, so a drop there could affect sdcard.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Sat Sep 29, 2012 9:05 am

Kekule wrote:I could be way off base, but from my understanding the core_freq configuration effects the L2 cache frequency. Could this all be related to some issue with the cache?
The L2 cache is always used, so this doesn't explain users with sdcard corruption running reliably from USB/nfs.

Dietmar
Posts: 361
Joined: Sun Sep 04, 2011 5:43 pm
Contact: Website

Re: Overclocking

Sat Sep 29, 2012 10:17 am

Hi all,
I can confirm the crash of my Sandisk 8 GB extreme card, using the Turbo Mode from configurations tool,
during the compiling of Qemu, brrr :? .

But with the settings

Code: Select all

arm_freq=1000
gpu_freq=333
core_freq=500
sdram_freq=500
over_voltage=8
force_turbo=1
current_limit_override=0x5A000020
all works fine :mrgreen: ,
greetings Dietmar

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Sat Sep 29, 2012 10:26 am

@dom: If you are unable to reproduce this corruption, I'll happily post you my board that fails at 750/255/+3 if the Foundation can send me a replacement in return (preferably one that hits 1200 with no over volting... only kidding).

I'm in the UK. Will even throw in a Transcend Class 10! :)

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5370
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Sat Sep 29, 2012 11:45 am

milhouse wrote:@dom: If you are unable to reproduce this corruption, I'll happily post you my board that fails at 750/255/+3 if the Foundation can send me a replacement in return (preferably one that hits 1200 with no over volting... only kidding).
Thanks for offer, but I'm still feeling your failure case isn't the typical one.
I think if Tompen (or others) can identify that a github commit that causes the corruption, that's the most promising avenue.

Tompen
Posts: 20
Joined: Tue Aug 14, 2012 4:11 pm

Re: Overclocking

Sat Sep 29, 2012 2:19 pm

For me, the corruptions get introduced in this commit:
c2c114a0
Fix for 'Failed to add service' try two
# uname -a
Linux XBian 3.1.9+ #202 PREEMPT Wed Jul 25 22:11:06 BST 2012 armv6l GNU/Linux
# /opt/vc/bin/vcgencmd version
Jul 28 2012 02:53:14
Copyright (c) 2012 Broadcom
version 328039 (release)

I know this does not match my previous post. I can not explain that. Because results from my testing did not make sense, I went back and tested 0d88fba0 several times and it works OK. I must have either done that test wrong the first time when I got corruption, or my notes was wrong. I spent hours on 0d88fba0 and I can not get corruption with 0d88fba0.

My testing results are consistent. That is: They are not intermittent. The only exception I have had is the 0d88fba0, that is why I believe some error was made on my part in the first test on that commit.

I am confident in the above, but to make absolutely sure, I will do som further tests with a couple of older revisions to try and get corruption any way I can think of.

I have now done my wget && tar-xvf test three times (switching up and down between revisions) with same result:
With c2c114a0 I get corruption directly (but only with core_freq=300, without corefreq=300 it works OK). With d535b28c those same tests pass without problem both with and without core_freq=300.

After this round of stress testing on d535b28c that is needed + a couple of older revisions, I will start isolating indvidiual files. If it start.elf or kernel.

Return to “Advanced users”