Overclocking discussion
-
@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
-
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=6It 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.
-
deleted
-
@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.
-
@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.
-
@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.
-
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.
-
@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.
-
@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.
-
@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.
-
You could always try to delid the IHS and apply liquid metal.
-
@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 -
@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.
-
@quicksilver Ok then, I thank you, you saved me a lot of time. I am glad I asked here.
-
@rion said in Overclocking discussion:
You could always try to delid the IHS and apply liquid metal.
That was an interesting video. It looked like some hefty glue. I think direct die cooling definitely works. It's as stripped down as you can get before making contact.
It seems the BIQU and Flirc use the same basic cooling technique. Which is "case heatsinking" I would call it for short by making direct contact with the chips. The BIQU does 3 things different/better.
It comes in direct contact with all 3 main chips (Flirc only 1 chip), it uses solid aluminum alloy columns (Flirc uses hollow aluminum alloy columns), The BIQU uses grease (Flirc uses thick tape or a very thick layer of grease). These differences make a 10 to 20 degrees Celsius difference.
The BIQU and "open case" are kind of go about it entirely different. The BIQU of course "case heatsinking". The open case relies more on open air dissipation and the use of fans to move the heat away quicker. I used tape on the open case but grease might drop those temps possibly.
I think that would be a good test. Thin tape vs. thin grease. We know thick tape vs thick grease is no contest except it does hold much more solid. Which might be more important than cooling in some scenarios. At a minimum it might be a mute point of a degree or two. I will test that at some point.
The only way I see to improve the open case is a bigger heat sink because the gap between the chip heatsink and fan ( which is air) has a higher resistance vs. metal on the BIQU which has proven to be more effective. Even when the case is fully heated up and under load.
The BIQU might run a bit cooler with passive venting on the top (like those cool raspberry Pi cut outs--also avoiding the use of fans). That way "general" heat buildup from other components that has to dissipate through the walls can just rise up naturally through the venting, as heat likes to rise. The BIQU does have a good size slot for a ribbon on the side that probably does allow a good amount of heat to escape but the Flirc is closed up solid on the sides and open on the bottom only.
-
@riverstorm said in Overclocking discussion:
The BIQU uses grease
I just want note something. My BiQU doesn't come with grease and so I used it without. Didn't know it comes with, thought you applied it from somewhere else. When I applied thermal paste from my desktop pcs cpu, it made the difference (20 degrees). Just in case someone gets the BiQU without grease or something else.
-
@thelostsoul said in Overclocking discussion:
I just want note something. My BiQU doesn't come with grease and so I used it without. Didn't know it comes with, thought you applied it from somewhere else.
You're right, that's a good point. It would need to be ordered separately and it would raise the overall price of the BIQU. I must have about 10 syringes at home so I almost take it for granted when I grab one.
-
@riverstorm said in Overclocking discussion:
The only way I see to improve the open case is a bigger heat sink because the gap between the chip heatsink and fan ( which is air) has a higher resistance vs. metal on the BIQU which has proven to be more effective. Even when the case is fully heated up and under load.
I've been linking to this before but this is the best passive cooling solution i have seen so far.
This modification with an acrylic sheet would've be possible to do on the official case and the nespi for example. But instead of using super glue you could attach the heatsink with epoxy to the sheet instead.
-
@rion Looks massive. But is it better than BiQU, where the whole case is a heatsink, touching also the other two chips. Oh btw, I see I saw that video already and commented it.
-
@rion said in Overclocking discussion:
I've been linking to this before but this is the best passive cooling solution i have seen so far.
That's impressive. I think he was only using thermal grease. I like how he made the sheet plastic shield to protect against shorting. Also the hot glue is smart. It holds it in place but very easy to remove.
The no sink, small heatsink and copper plate were all close within a few degrees. Temps definitely scale with the size of the heatsink. 30C difference between none/small to large. It seems more important to remove it from the immediate chip and once on the heatsink/case the Pi just runs cooler.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.