Overclock Wiki

Riverstorm

I had one other concern running the sdbench, wondering by chance if you knew the answer. During the test, it says that it's writing 512mb of data or something along those lines.

I think it runs it's own maintenance task and cleans up after itself. No virtual sprawl of files all over! :)

I was asking if you could think of any scenario in which a game or application currently attainable on the pi, would create a similar strain caused by the sysbench and cpuburn tests?

Dank is right. I had no idea my settings were unstable until I actually encountered my problem when downloading experimental packages via source. During that process it really pushes the Pi at a time you don't want corruption.

theWinterDojer

@riverstorm Oh wow, okay then, I will probably stay clear from those unless there is something I absolutely need. To be honest I don't think I've even looked at what's there.

Edit: There was something else I meant to ask you. For gpu_mem, I've heard memory splitting hasn't really been necessary since Pi 2. Do you think it's something I should look into?

Riverstorm

@thewinterdojer said in Overclock Wiki:

Edit: There was something else I meant to ask you. For gpu_mem, I've heard memory splitting hasn't really been necessary since Pi 2. Do you think it's something I should look into?

I think there's others that can answer that better and know how much is needed for ES, fancy themes or some of the other neat things people are doing that require more memory. I don't even remember why I bumped to 320 vs the default I think is 256 which is more than adequate I am sure for most things.

If there's an experimental package like AdvMAME, Daphne, ScummVM (there's some good ones) you want to run I would still do it. What I do is add my overclock settings to /boot/config.txt but comment them out. Then setup everything the way I want, make a backup, restore to a bigger SD card, expand it, enable the settings and copy over the bigger files for Daphne, etc.

That way I have a backup but also the original SD card as a secondary backup. I experiment on the bigger "production" card until I am comfortable with additional changes and tweaks then I go back to my original card to implement those changes. Then rinse and repeat back to the production card. The only time I wipe the original card is when a new image is released and I start from scratch. Just don't forget to backup those high score files before wiping your production card which I loose all the time. :)

I worry more about crashes and corruption when my arm_freq was to high. Heat not as much. If you get throttled during an install you're probably ok even though it's running slower.

With games that may push the card to throttle due to heat will be obvious when suddenly you take a huge performance hit stuttering and wondering what just happened. Still probably ok even though annoying. :)

If that's that case then you could look into some cooling solution either passive (i.e. - lower your overclock) or active (heatsink, fan, water). I suppose water is reserved for the elite building custom loops. I remember when it was that way with computers.

Now with these sealed closed loop systems being so cheap, readily available and easy to install it really puts them into the hands of the average consumer that doesn't need to have any fancy skills or knowledge. Just don't buy a Pi secondhand from the guy who was water cooling it. He probably pushed it way beyond spec! :)

theWinterDojer

@riverstorm

I'm going to look into some of the experimental stuff, I haven't heard of Daphne or ScummVM. That's actually a really good idea having a test and production card, I have an extra one lying around so I think I may do that as well!

Heat doesn't appear to be an issue with my build yet, got some high quality thermal tape w/ heatsinks and fan, it does the job just fine. I'm curious to see how it will go tonight when I run the tests. Thanks for all the info, I appreciate it.

joel_fm

@riverstorm reading through your posts, but I didn't see which hardware you're running these settings on, Pi 3 or 2?

joel_fm

@suprjami thanks for the answers on here, made a lot of confusing documents more clear. Wondering why however, on your base settings you set total_mem, as it's default with jesse and beyond, correct?

Riverstorm

@joel_fm said in Overclock Wiki:

@riverstorm reading through your posts, but I didn't see which hardware you're running these settings on, Pi 3 or 2?

Yes, on the Pi 3. I never tried testing the 2.

theWinterDojer

@riverstorm

I just got around to creating the script and I am getting an error: "Could not find watchtemp.sh".

This is what I did:

Created a file watchtemp.sh and copied your script into it
Place watchtemp.sh in /home/pi/
Made is executable with chmod +x watchtemp.sh
Run with watch watchtemp.sh

I tried naming it something else, but still got the same error. /home/pi/ is my home folder where I have other scripts including the stress tests. Am I missing something here maybe?

Riverstorm

@thewinterdojer said in Overclock Wiki:

I just got around to creating the script and I am getting an error: "Could not find watchtemp.sh".

I have it setup as bash alias. If you're in your home directory try watch ./watchtemp.sh. The . denotes the current directory and since it's not in your $PATH you use ./ to tell it where the executable is located. Anyway I think that should work.

theWinterDojer

@riverstorm I feel dumb, I should've known that. I will give it a try when I get home, thank you!

stoo

Sorry to necro this topic, but according to the following link, avoid_pwm_pll=1 was removed from the firmware in October 2015 and is now always enabled.

https://github.com/Hexxeh/rpi-firmware/commit/260bc9c7589b3359485fc02fed8f56d4c5eaad9a

Does this affect overclocking and, if so, how?

The Wiki still contains the following, which may now be incorrect. Does anyone know for sure?

By setting avoid_pwm_pll=1 (which negatively affects 3.5mm audio quality) you can overclock the individual GPU components with the parameters:

v3d_freq - speed of OpenGL 3D graphics processor

isp_freq - speed of Image Sensor Pipeline

h264_freq - speed of x264 video decoder (not used by emulators, used by Kodi)