The LEDs are driven directly by the LAN chip and are independent of any CPU activity.a9971256 wrote:I noticed that when I have no cooling system attached and the system crashes, the LAN ic is still blinking the LEDs, even when I ping it. Is that normal or is it a defect
So the limit of sdram=600? I've set 710 on my config.txt, I guess my Pi was ignoring this value. Is there a command to verify the sdram?dom wrote:600MHz is still the limit. I do need to investigate if increasing the 2.4GHz PLL limit, or using a smaller divisor is possible.shalo wrote:The ram used to have a hard cap at 600mhz which with early models Samsung hit very easily and Hynix were lucky to hit 500 with no overvolting so it may be worth pointing out which ram you have.
I assume this was 1/4 of 2400 or something and that this limit no longer applies?
I don't really understand how anyone is verifying anything. How did you test it to arrive at a figure of 710? If ~600 works, anything over 600 should work just the same. Seems odd that you would find a 710 figure.XBMCantgetenough wrote: So the limit of sdram=600? I've set 710 on my config.txt, I guess my Pi was ignoring this value. Is there a command to verify the sdram?
I don't understand how this is even really possible. Surely when you are overclocking the very first thing you do is run a simple benchmark to see how your new settings have changed things. With cpus it's usually something very simple like SuperPI 1M. You'll very quickly see some sort of quantitative result or a fail. Then you do a broader set of benchmarks that stress a little more, then finally you do an actual stress test to make sure it's stable. If it passes this final stability test, you might decide to push it some more. If it fails you look at your results and see if you are happy to give it more power or back off on the overclock which is usually a more considered decision back in the desktop world where heat can be the major factor.a9971256 wrote:I think my pi might have been ignoring 1400 MHz. It was staying down locked to 700 MHz. What art the proper ways to overclocking without raspi config? Do I have to change Linux settings to allow turbo to work dynamically. Also, in my pi application, my pi will stay on for 10 minutes and will be shut down, so cooling might not be a problem here. Powered by lead acid battery, psu shouldn't be an issue. LmM3940 gives 4.9 volts under pi 1 ghz usage with filter capacitor
The 710 came from increasing incremental steps. I didn't pluck 710 out of knowhere. If I go to about 720 It seems to crash more often (openelec) so I thought 710 must be valid, and its working at the speed. But that is what I thought about my core speed. I can set the core @700 and it boots but the Pi ignores it. But strangely enough If I set it at 720 then it doesn't even load. So logic tells me that it must have accepted thee 700 value. But running vcgencmd I can confirm I can't get past 600. And at 560 I get a increase in fps (openelec) as apposed to setting core@700. So thats why I would like to know if there is a way to measure the ram. And plus it would be helpful if this limit for the varaibles is written in http://elinux.org/RPiconfigshalo wrote:I don't really understand how anyone is verifying anything. How did you test it to arrive at a figure of 710? If ~600 works, anything over 600 should work just the same. Seems odd that you would find a 710 figure.XBMCantgetenough wrote: So the limit of sdram=600? I've set 710 on my config.txt, I guess my Pi was ignoring this value. Is there a command to verify the sdram?
When you set overclock with raspi-config, it adds a script to /etc/init.d that runs at boot and switches the CPU governor to the "ondemand" governor (and tries to detect if the shift key is held down to skip this, in case you overclock too far).a9971256 wrote:What I am trying to find out is when you use raspi config, does it change any settings within Linux that controls the dynamic clocking?
Are you sure this is still the RAM limit? I used to be able to put in any number higher than 600 just fine. Now if I put in 700 or higher the Pi only makes it halfway through the boot process before spitting errors and freezing.dom wrote:600MHz is still the limit.
Have you tried overvolting sdram, mine works but starts to reboot on heavy load, once every 10 mins after intial 30 minutes of on. Also use this which helps disable_pvt=1. I've gotten 710 working but like i said its not stable for longportets wrote:Are you sure this is still the RAM limit? I used to be able to put in any number higher than 600 just fine. Now if I put in 700 or higher the Pi only makes it halfway through the boot process before spitting errors and freezing.
The Pi is actually faster than the 3GS when in turbo mode. The 3GS is capable of 1200 DMIPS, and the Pi is capable of 1250 DMIPS when overclocked to 1000MHz ARM. That number is even higher when core_freq is doubled in turbo mode. The Pi also has double the RAM than the 3GS. And as you mentioned, the Pi has a much faster GPU.a9971256 wrote:why does the pi have such a wimpy processor? The gpu is overrated because many times the processor ain't fast enough for the gpu. my iphone 3gs has a better processor compared to pi but has a worse gpu (i believe it has an equivalent to the VideoCore II). is there a board with the TI A15? A15 Keystone processor running at 5.6GHz seems overkill.
Do you mean sdram_freq=500 with over_voltage_sdram=1? since why would you want to increase volts to sdram if its stable @ 450? and by changing the volts to sdram I'm assuming that your intentions was to increase sdramfernandovg wrote:dom, I'm using this settings for a while:
and its stable (gpu_mem is higher because I was getting problems with subtitles. There were showing as blocks and not chars)
Can I add?
Code: Select all
hdmi_force_hotplug=1 hdmi_mode=32 arm_freq=1050 core_freq=500 gpu_freq=500 sdram_freq=500 over_voltage=6 disable_overscan=0 gpu_mem=155 start_file=start_x.elf fixup_file=fixup_x.dat