Overclocking discussion

[thelostsoul]

@riverstorm A really good test, thank you for all your insight. There are some suprises and I am happy to own the BiQU too and its cheap (pricely wise). But on the testing for the Flirc2 case, you used a lot of thermal paste, right? But is this not counter productive? If you use too much thermal paste, this will not perfectly transfer the heat to the heatsink/case. Normally there should only be a "thin" layer of thermal paste, as this will just close the microscopic holes between chip and heatsink. Maybe a better idea is to get a very thin and small heatsink between?

Hopefully I didn't misunderstood you here.

A general question: Do you guys cool down after one test? I mean, if the case is already hot, then it will not last as the first test right? And tests are going 3 hours, that would mean a sort of 6 hours test for the second one.

[thelostsoul]

I am currently testing and experimenting with some settings; it started to be a lot of fun too and SSH/Putty is working too, I can finally measure the temps while benchmarking. And thanks to the patience of quicksilver in the other thread, I manage to get higher settings.

But what I wanted to say is, using thermal paste on BiQU case made a BIG difference, up to -20°C!? I am not 100% if this can be true. Do you use any thermal paste or are you using tapes or nothing (like me before). This case rocks!

Btw, I found this part in the documentation and it worries me a little if some recommendations have any effect if this one is in not use:

"
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)

"
Source: https://retropie.org.uk/docs/Overclocking/

Does that mean, without avoid_pwm_pll=1 the setting v3d_freq will have no effect? The v3d_freq is recommended in many websites without the mention of avoid_pwm_pll=1. Btw, as I am using the 3.5mm audio jack, I can't disable this.

Another thing from the documentation on same page. What does the setting total_mem=1024 do? At the (official?) page for Raspberry Pi 3 config file https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md, I cannot find total_mem.

[quicksilver]

@thelostsoul I'm not sure you need to set avoid_pwm_pll=1 anymore. You can test by running a game, then ssh and type:

vcgencmd measure_clock v3d

[thelostsoul]

@quicksilver I did this while Quake 3. The result is:
frequency(43)=525000000
What does this tell me?

[quicksilver]

@thelostsoul it tells me you set your v3d frequency to 525mhz

[thelostsoul]

@quicksilver Ah yes haha, I did. So that means its in effect and the other setting is not needed? Maybe the documentation needs a change there.

[quicksilver]

@thelostsoul said in Overclocking discussion:

@quicksilver Ah yes haha, I did. So that means its in effect and the other setting is not needed? Maybe the documentation needs a change there.

Yea it would seem so unless there is something I'm missing.

[Riverstorm]

@thelostsoul said in Overclocking discussion:

@riverstorm But on the testing for the Flirc2 case, you used a lot of thermal paste, right? But is this not counter productive?

Yeah it is [way to much grease]. At home I have an old Ivy Bridge I have overclocked to 5GHz using air in a push/pull configuration. The amount of thermal grease I used about the size of a piece of rice.

With the Flirc 2 the tape that ships is somewhere between 1 to 2 MM and I believe it gets slightly compressed when applied and the case screwed closed. It's very difficult to take them apart once that tape takes hold. It's a slow process of prying with a thin screwdriver around the edges working the Pi up and out.

I figured I would try grease vs. tape just to see how if it would perform and was surprised it was around 10C lower. That gap is huge and the OEM thermal tape thickness is a bit ridiculous so I had to use a ridiculous amount of grease to fill the gap. I cold pressed it and would lift to view it until most of the chip was covered (nothing like conventional PC rules). To me the take away is even a thick layer of thermal grease blows away thick thermal tape.

I agree you could maybe use thermal glue with a piece of copper, etc. to lower the case column so only a thin layer of grease or tape is all that's needed would make all the difference. It would take some trial and error to get a piece of metal of the proper thickness. I was more going for testing out of the box.

A general question: Do you guys cool down after one test? I mean, if the case is already hot, then it will not last as the first test right? And tests are going 3 hours, that would mean a sort of 6 hours test for the second one.

Yes my test was very informal and I didn't do a full cool down in between even though they drop quickly when you exit Q3. It was basically for fun. If you do any testing definitely post any results.

20C cooler seems to be on on par. The BIQU and open case performed similar. One being grease and one tape even. I used grease on the BIQU and tape on the open case.

The Flirc 2 I tried both tape and grease. The Flirc 2 contacts only the main chip but the BIQU contacts all 3 main chips. Once grease was applied to the Flirc 2 it dropped 10C which bought it within 10C or of the other 2 cases.

Also I sanded the paint off the case columns to make better contact with the chip.

The cases run very warm. My ear thermometer I knows goes to at least 105F/40.5C but it read 'high'. It has a nice round flat contact point that I would put right on the flat part of the case. When you think about it the whole case is basically the heatsink so it just radiates heat.

@quicksilver - I definitely need to do some more testing but man it can go for days. A few times the settings I was testing made it over an hour or more before crashing. Other settings would crash back to the game selection screen. I figured if it crashed even once it was to high. When I did hit the stable numbers it was a straight 9 to 10 hours of perfection.

I figure I have room for improvement since those exact numbers worked on 3 other Pi's I have on hand. The burn in was only about 1 hour each for those Pi's so they might be unstable. The final numbers on the main Pi might be slightly conservative but they are rock solid. I will try and bump a little higher and see if I can find the 'absolute' cap.

Here's a script I like to use. It converts the temps of the CPU and GPU to nice and easy to read Celsius. I use this script in conjunction with the watch command so it updates every few seconds. Basically "watch temps.sh"

#!/bin/bash
cpuSpeed0=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
cpuSpeed1=$(($cpuSpeed0/1000))

cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))

gpuTemp0=$(/opt/vc/bin/vcgencmd measure_temp)
gpuTemp0=${gpuTemp0//\'/°}
gpuTemp0=${gpuTemp0//temp=/}

echo
echo CPU Speed: $cpuSpeed1" MHz"
echo
echo CPU Temp: $cpuTemp1"."$cpuTempM"°C"
echo GPU Temp: $gpuTemp0

[thelostsoul]

I am currently still running benchmark to find the limits. It seems to be that I am a bit lucky. My current settings are:

arm_freq=1400
core_freq=525
fpu_freq=525
v3d_freq=525
sdram_freq=575
sdram_schmoo=0x02000020
sdram_over_voltage=6
over_voltage=6

It is running Quake 3 with 8 bots for 1h and 10 minutes now (2h test now success). The temperature is constantly between 60°C and 62°C. I only saw it once after 15 minutes going back to 0.6ghz and never again. And if it did, why did this happen at this degree of heat? I hope the internal calculation for the temp is not broken. Otherwise, I feel thats ok happening once per hour. it runs so cool, I just feel there must be some room for going even further.

Edit:
I am currently testing 1.45ghz and it seems to be working too at around 61°C -- whats going on here?! I'll let it run for at least 2h now. With my previous case I had heat issues even without overclocking.

@riverstorm said in Overclocking discussion:

20C cooler seems to be on on par. The BIQU and open case performed similar. One being grease and one tape even. I used grease on the BIQU and tape on the open case.

Just to be on clear side, I was meaning that I used BiQU case without thermal paste for the first few days and when I applied thermal paste, it reduced another whopping -20°C on top of what BiQU did on its own.

[thelostsoul]

deleted

[quicksilver]

@thelostsoul it's possible your pi can handle a fair amount of overclocking. My pi will eventually crash Q3 if I set GPU to anything higher than 505mhz. Also, gpu_freq sets core freq and v3d freq. So if you are setting them to the same value, you only have to set GPU freq.

[Riverstorm]

@thelostsoul said in Overclocking discussion:

Just to be on clear side, I was meaning that I used BiQU case without thermal paste for the first few days and when I applied thermal paste, it reduced another whopping -20°C on top of what BiQU did on its own.

Ah ok, I see what you were saying now.

only saw it once after 15 minutes going back to 0.6ghz and never again.

This sounds like the governor potentially. I had a game that kept stuttering and the issue was the governor setting. If you set it to 'performance' it will use the overclock settings until you exit the game. Even though as you said it only happened once maybe it is more frequently but Q3 is so busy you hardly notice but enough to keep it cooler. Here's the link to the governor settings if you don't have it.

That script was really helpful for me in catching that also as it shows the current speed. I create a bin directory off my home directory or wherever you like, I created an alias for it so I can run it anywhere. You also need to chmod +x <script> to make it an executable. I use it with Putty.

I'll ditto what @quicksilver was pointing out some of your settings are redundant and unneeded as the GPU setting sets several with the one command. Yep you definitely can get more speed out of your Pi than mine if you test stable.

[thelostsoul]

@riverstorm @quicksilver About the redundant settings, it started with different settings and when I experienced problems with too high overclocking, I reduced it to same settings and then I will go upwards slightly. So, its just a placeholder for now.

For the governor setting, I was also wondering what it does. Now that I know it, I am not sure if I will use it. I think it is ok, if it goes down when not fully needed, so the cpu is not 100% of the time under full stress, even if it sits there and doing nothing or if I play undemanding games (most of the time). The games where I get stuttering don't already doing full stress on cpu (I'll watch it through Putty too). In which game did it help, where you had stuttering and governor was the solution?

Btw, I deleted my above message, but now I rethink about to repost it again. Can you guys play N64 Yoshi's Story? Without the overclocking, it was unplayable slow and stuttering. With the overclocking settings, its smooth, but on some point, the game gets crazy and everything glitches out until nothing works anymore. I could test this over and over again with different overclock and emulator settings, but I think its easier for me, if you guys already know the answer. The glitch happens in first level at the guy with stop sign. Stomping on the ground starts the glitch and then it gets worse every second.

[Riverstorm]

Now that I know it, I am not sure if I will use it. I think it is ok, if it goes down when not fully needed, so the cpu is not 100% of the time under full stress, even if it sits there and doing nothing or if I play undemanding games (most of the time).

You're in luck. The 'performance' setting starts at game launch and resets at game exit so it will throttle and sit idle at game exit. Check the speed during game and on game exit to see in action.

I'll have to defer the N64 games to @quicksilver as I don't them very well.

[thelostsoul]

@riverstorm said in Overclocking discussion:

You're in luck. The 'performance' setting starts at game launch and resets at game exit so it will throttle and sit idle at game exit.

Oh, thats an important information! So, then it makes really sense to use this setting. But for now, I will first play and watch Putty.

[Riverstorm]

@thelostsoul said in Overclocking discussion:

@riverstorm said in Overclocking discussion:

You're in luck. The 'performance' setting starts at game launch and resets at game exit so it will throttle and sit idle at game exit.

Oh, thats an important information! So, then it makes really sense to use this setting. But for now, I will first play and watch Putty.

Yeah the way I understand it is when the game launches it will use the setting specified by the governor setting and then it goes back to the default and throttles to 600 on game exit while sitting at the game selection or in Emulationstation, etc. That way you get maximum performance while gaming only and save a little wear and tear when not playing. I set this option always but I think it's a good option to set while overclock testing for stability and heat testing.

[quicksilver]

@thelostsoul which emulator/plugin are you using for Yoshi's story? There is a know issue right now with mupen64-glide on the pi right now that is bugging games out after about 10-20 minutes of playtime. It's currently being investigated.

Edit: Just tested Yoshi's story. This is a different issue than the one I mentioned above. Yoshi's story must be on the mupen64 config blacklist because no matter which plugin I pick it reverts to using mupen64-glide. I tested using lr-mupen64 (which doesn't look at the blacklist) and was able to get past the glitch. However just a little further into the game, the glitch occurred and it froze the emulator.

I was able to force Yoshi's story to use mupen64-rice by disabling the mupen64 compatibility check. There are some visual glitches using rice but it doesn't have that same gamebreaking bug that glide does.

[Rion]

You could always try to delid the IHS and apply liquid metal.

[thelostsoul]

@quicksilver I tried different emulators for quick testing. Don't remember which one exactly, but the recommended one from compatibility list in documentation, the mupen64 auto setting and one random.
Its frustrating, because it starts working so good, almost perfect until the glitch happens. So, which problem is it? Is there a thread for? So i don't off topic here anymore. :D

[quicksilver]

@thelostsoul it doesn't matter which emulator you pick to try to run Yoshi's story. It forces mupen64-glide (if you see the fps counter it's using glide). You can use mupen64-rice but only if you remove the compatibility check. Mupen64-rice has some visual glitches running Yoshi's story but that glitch doesn't occur.

I don't know if there is an existing thread for this issue. There are quite a few n64 games that have issues like this only on the pi. It's usually due to the fact that the Pi's GPU drivers are old garbage and don't have certain features.