Overclocking


1126 posts   Page 16 of 46   1 ... 13, 14, 15, 16, 17, 18, 19 ... 46
by dom » Thu Sep 20, 2012 10:41 am
malakai wrote: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?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by dom » Thu Sep 20, 2012 10:42 am
hojnikb wrote: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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Cino » Thu Sep 20, 2012 12:28 pm
dom wrote:
Trey wrote: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.
Posts: 2
Joined: Tue Aug 14, 2012 2:09 pm
by 0117blocky » Thu Sep 20, 2012 12:37 pm
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.
Posts: 43
Joined: Mon Apr 30, 2012 8:03 am
by XarothBrook » Thu Sep 20, 2012 1:17 pm
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 ?
Posts: 8
Joined: Thu Jul 26, 2012 10:37 pm
by hojnikb » Thu Sep 20, 2012 1:37 pm
dom wrote:
hojnikb wrote: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 :lol:
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian
User avatar
Posts: 109
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home
by dms75 » Thu Sep 20, 2012 2:15 pm
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
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by dom » Thu Sep 20, 2012 2:19 pm
XarothBrook wrote: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.
XarothBrook wrote: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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by dom » Thu Sep 20, 2012 2:27 pm
dms75 wrote: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).
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by XarothBrook » Thu Sep 20, 2012 2:40 pm
dom wrote: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...)
Posts: 8
Joined: Thu Jul 26, 2012 10:37 pm
by Salamander » Thu Sep 20, 2012 3:31 pm
dom wrote: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.
User avatar
Posts: 49
Joined: Fri Mar 30, 2012 1:41 pm
by dom » Thu Sep 20, 2012 3:38 pm
Salamander wrote: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):
viewtopic.php?f=29&t=6201&start=325#p170793
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by shalo » Thu Sep 20, 2012 4:26 pm
fangfufu wrote: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.
Posts: 74
Joined: Tue May 08, 2012 7:25 pm
by n1ght28 » Thu Sep 20, 2012 4:27 pm
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?
Posts: 6
Joined: Thu Sep 20, 2012 4:20 pm
by dom » Thu Sep 20, 2012 5:04 pm
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?

What does
uname -a
report?
What about:
dmesg |grep cpufreq
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by okazou » Thu Sep 20, 2012 7:03 pm
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! ;)
Posts: 4
Joined: Sat Mar 03, 2012 8:57 am
Location: Montreal
by edd247 » Fri Sep 21, 2012 4:19 am
Code: Select all
cat /proc/cpuinfo |grep Revision
Revision        : 0002

does this mean my warranty is void?
Posts: 8
Joined: Tue Sep 04, 2012 6:13 pm
by milhouse » Fri Sep 21, 2012 4:26 am
edd247 wrote:
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.
Posts: 613
Joined: Mon Jan 16, 2012 12:59 pm
by edd247 » Fri Sep 21, 2012 4:30 am
milhouse wrote:
edd247 wrote:
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
Posts: 8
Joined: Tue Sep 04, 2012 6:13 pm
by jumon » Fri Sep 21, 2012 5:00 am
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!
Posts: 3
Joined: Fri Sep 21, 2012 4:56 am
Location: Texas, USA
by RaTTuS » Fri Sep 21, 2012 8:00 am
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
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe
User avatar
Posts: 9276
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
by dms75 » Fri Sep 21, 2012 8:14 am
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
Posts: 25
Joined: Mon Aug 06, 2012 1:41 pm
by dom » Fri Sep 21, 2012 9:14 am
dms75 wrote: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.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5086
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by meigrafd » Fri Sep 21, 2012 11:56 am
is it somehow possible to get temperatur and frequency displayed with phpsysinfo ? lm-sensors cant detect it :(
Posts: 92
Joined: Tue May 29, 2012 9:28 am
Location: Germany
by nicknml » Fri Sep 21, 2012 12:17 pm
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 :)
Posts: 192
Joined: Thu Mar 15, 2012 8:44 pm