Overclocking discussion

quicksilver

Just watched a video ETA Prime put out, looks like he got his Pi 3b+ to run Conker's Bad Fur Day . Looks like a very playable framerate too. His overclock settings are a bit wonky though.

Riverstorm

@quicksilver said in Overclocking discussion:

Just watched a video ETA Prime put out, looks like he got his Pi 3b+ to run Conker's Bad Fur Day .

I am not quite as up on consoles games. I do have the classics mainly. One of the challenges for me on the N64 is trying to get the d-pad (hat) working. I tried using lr-mupen64plus. Everything seems to work fine except making changes for saving/loading. For incrementing/deincrementing my save slot I can press hotkey+right (or left) which is defined in all/retroarch.cfg and that works fine. To save/load I have hotkey+up (or down) defined in all/retroarch.cfg but that doesn't work. What works is defined in the mupen64plus.cfg.

It has in that config file "J0B8/B4" which works fine but I wanted to change it to "J0B8H0V4". Looking at the docs on mupen64plus. It's Joystick 0 button 8+button 4. So that longer string with the H is Joystick 0 button 8+hat 0 direction down (V is value and 4 is down). It's pretty straight forward but the emulator doesn't seem to recognize the H variable defined on the mupen64 docs page.

On topic before doing any testing I have the Cana Kit power supply it's black (US plug) but on their site I see they have a white one (universal plug) that says official are they the same? I can't really find the answer/difference between the two but they both show as certified working with all Pi versions.

quicksilver

@riverstorm What controller are you using?

I have the canakit black plug too. I would assume its the same as the white one, if the specs are the same.

Riverstorm

It looks to be the same specs https://www.canakit.com/official-raspberry-pi-power-supply.html

Riverstorm

@quicksilver said in Overclocking discussion:

What controller are you using?

Missed that they are XBOX 360s with wireless dongle. I have wired also.

quicksilver

@riverstorm In reference to your issue with the dpad and N64, I'm not sure that lr-mupen64 looks at the mupen64 config file your referred to. I'm fairly certain that config only influences settings for stand-alone mupen64.

Riverstorm

@quicksilver said in Overclocking discussion:

@riverstorm In reference to your issue with the dpad and N64, I'm not sure that lr-mupen64 looks at the mupen64 config file your referred to. I'm fairly certain that config only influences settings for stand-alone mupen64.

That's the strange thing but I am not real familiar with the N64 emulator as there's a lot going on it seems. Here's what is in my /opt/retropie/configs/all/retroarch.cfg

# Saves state.
input_save_state = "up"
# Loads state.
input_load_state = "down"

# State slots. With slot set to 0, save state name is *.state (or whatever defined on commandline).
# When slot is != 0, path will be $path%d, where %d is slot number.
input_state_slot_increase = "right"
input_state_slot_decrease = "left"

Here's what's in my /opt/retropie/configs/n64/mupen64plus.cfg

# Joystick event string for saving the emulator state
Joy Mapping Save State = "J0B8/B4"
# Joystick event string for loading the emulator state
Joy Mapping Load State = "J0B8/B5"
# Joystick event string for advancing the save state slot
Joy Mapping Increment Slot = ""

I can increment my save slot with select+dpad right or left as shown in retroarch.cfg but I can not save with select+dpad up or down.

What I can do is save with select+button 4 and 5 (the shoulder buttons). If I remove the J0B8/B4 and J0B8/B5 I can't save.

It's like retroarch is working for incrementing save slot 0, 1, 2, etc. but using the mupen64plus.cfg for save games.

I hope that makes sense.

quicksilver

@riverstorm Which emulator specifically are your trying get this to work in? Lr-mupen64 or stand alone mupen64? Because each of those configs are for completely separate emulators. Are you testing using the same game and emulator each time?

Riverstorm

@quicksilver said in Overclocking discussion:

Are you testing using the same game and emulator each time?

I know that's the weird part and I thought maybe I am missing something obvious because there's a lot in N64 I just don't know. I am using lr-mupen64plus. I set it as the default when booting a game and pressing any key for the Quick selection menu. I was hoping to use the unified input from Retroarch. The game is Castlevania 64 and it yields consistent results every time.

quicksilver

@riverstorm Ok so the correct settings for lr-mupen64 should be found in /opt/retropie/configs/all/retroarch.cfg

settings in /opt/retropie/configs/n64/mupen64plus.cfg only applies to the standalone mupen64.

When I get home I will mess with this a bit and see if I can get it working. So if I understand correctly you want to make hotkey+up or down on the dpad save and load state?

Riverstorm

@quicksilver said in Overclocking discussion:

So if I understand correctly you want to make hotkey+up or down on the dpad save and load state?

Yes that's exactly it. Here's the docs on the Mupen64Plus Core Parameters settings which explains it well just in case you don't have it. It explains it well. Like you said though it shouldn't be needed and only a quick modify to all/retroarch.cfg should work. The settings I have a pasted above directly from my retroarch.cfg and mupen64plus.cfg.

A quick note I did test stable with a stock image and only Q3 loaded using a Cana Kit power supply and a SanDisk SD Card. You recommend next overvolting to 6 and then what's a good starting arm_freq? It does 1200 at stock. I use a small program with 'watch' in a putty window to measure temps.

quicksilver

@riverstorm said in Overclocking discussion:

Yes that's exactly it. Here's the docs on the Mupen64Plus Core Parameters settings which explains it well just in case you don't have it. It explains it well. Like you said though it shouldn't be needed and only a quick modify to all/retroarch.cfg should work. The settings I have a pasted above directly from my retroarch.cfg and mupen64plus.cfg.

When you change the settings in the all/retroarch.cfg, do your changes work in other libretro emulators (like for snes, sega genesis etc.)? Is it only lr-mupen64 that the changes dont work?

A quick note I did test stable with a stock image and only Q3 loaded using a Cana Kit power supply and a SanDisk SD Card. You recommend next overvolting to 6 and then what's a good starting arm_freq? It does 1200 at stock. I use a small program with 'watch' in a putty window to measure temps.

I would try 1300mhz first. It seems most pi3s are stable at that speed. If it crashes after a few hours then you know yours cant hit 1300. Dont change anything else though otherwise you will never figure out what setting is causing the crashing. Which emulators are you trying to improve?

Riverstorm

@quicksilver said in Overclocking discussion:

Is it only lr-mupen64 that the changes dont work?

Thanks for asking I just tested and save/load doesn't work. Shoot something else is wrong. I did a rebuild from scratch image 4.3 and updated RetroPie to 4.1.6, updated Retroarch (current from yesterday), Emulationstation (2.7.5RP) & lr-mame2003. I left everything else the same. I am sure it was working prior. I will test at lunch with an old build I have. My test emulators are lr-mame2003 & lr-fbalpha running under the Arcade folder. Save doesn't seem to be working. I have no idea what to look at but that's copied and pasted directory from my all/retorarch.cfg. The arcade/retroarch.cfg is blank except for 2 shader lines.

# Saves state.
input_save_state = "up"
# Loads state.
input_load_state = "down"

EDIT: Player controls from all/retroarch.cfg

input_player1_up = "up"
input_player1_down = "down"

Riverstorm

@quicksilver I spent some time last weekend doing some overclock testing and came up with some interesting results. It took several hours of reboots through out the weekend but last Saturday afternoon I hit my magic numbers finally.

I had no crashes for about 9 to 10 hours straight. The frag count on all 8 characters (9 including my character which was zero frags ;) was around 2000 to 2200 each. They are surprisingly evenly matched. :)

It seems there's some wiggle room. If I lowered the sdram freq low enough I could get a bit more from the arm freq or vice versa but with Quake 3 there was no wiggle room on the gpu freq. Q3 beats the hell out of the GPU. It was somewhere between 500 to 525 but I haven't nailed down the exact number yet. It's not exact science but a lot of playing with high/low numbers, different voltages, etc. really changed things up.

Also of note I have a good quality HP 2.0A 5.3V power supply that tested perfect with Q3 for about 4 to 5 hours. It's uses a standard USB detachable cable on the power supply side.

Another interesting thing is I also tested a 10 foot/3 meter USB cable and it wasn't stable. Even at stock clocks I was getting low voltage warnings. The longer the cable the bigger the vdroop.

I used a Pi 3, Cana-Kit 2.5A power supply and G. Skill 64GB Class 10 micro SD card.

100% stable overclock settings running Quake 3:

# CPU Overclock
arm_freq=1325
over_voltage=6

# GPU Overclock
gpu_freq=500

# RAM Overclock
#over_voltage_sdram = 6
sdram_freq=550
sdram_schmoo=0x02000020
over_voltage_sdram_p=6
over_voltage_sdram_i=4
over_voltage_sdram_c=4

# SD Card Overclock
#dtparam=sd_overclock=100

After that I tested 3 cases on Sunday idle and under load. The standard open case (posted below), BIQU and Flirc 2. The BIQU and Flirc 2 are easy to look up online but I wanted to post the open case pics so you can see exactly which one. It has a fan and also heatsinks on the SoC, ethernet and underside memory chip.

The ambient was roughly 69F/20.6C. The "burn in" for idle and load were about 30 minutes each. Also I did not have original thermal tape for the Flirc 2 and used a 3M piece I had on hand. This is worth noting in case the original tape had potential to perform better.

Air is more resistant then metal so the open Pi case never really got hot due to the fan but does run slightly warmer under load then the BIQU case. I tried to read the temp of the BIQU case with an ear thermometer but it the read only 'HIGH' on the display and not the actual number.

I wish I had an IR infrared thermometer to read the actual temp. For all it's heat it was the coolest running case and the next day after the 9 to 10 hour burn in it was a full 2C cooler under load. My guess is the thermal grease was settled in and curing as the ambient was the same and in the same location.

You have to hit that sweet spot of not to much grease but enough as some of it oozes around the very thin columns of the BIQU case and covers more of the chip surface. Like a beveled edge up the column. I am not sure how to explain it but application is another topic entirely.

Idle was sitting at the Emulationstation selection screen.
Load was running Q3 with 8 players (9 total including my character). The main (first) map and selecting 1 of each character plus a few duplicates.

BIQU Case:

Idle - 37-38C
Load - 62-63C

Open Case:

Idle - 39-41C
Load - 67-68C

Flirc 2 Case (tape):

Idle - 45-46C
Load - 80-82C

Flirc 2 Case (grease):

Idle - 39-40C
Load - 70-71C

Screwdriver:

Idle - N/A (not tested)
Load - 81-84C

After that I decided to have a little fun and found some surprising results. What I did was remove the tape from the Flirc 2 and replaced it with thermal grease, a lot! It's the only way to bridge the monster gap between the column and SoC. I am sure the PC guys will have a coronary looking at the pic.

The numbers actually surprised me both idle and under load. A pic of how much grease I used is posted below. Both the Pi and case had equals amount but only the Pi is shown below. If you look close you can see where it heated up and ran to the edges of the chip. It's smooth around the edge of the pile of thermal grease.

Looking at the numbers I think there's a design flaw with the Flirc 2. The gap needs narrowed to utilize thinner tape or grease. It's idle temps with grease were as good as the BIQU and open case and a bit higher under load than the open case. It still performed the worst but way closer to the other two with grease vs. tape.

The other note on the Flirc 2 was I figured it would run a few degrees cooler with the top off and uncover the hollow heatsink column but surprisingly it was only about 1 maybe 2 degrees Celsius cooler that way.

My final test was a completely open Pi, no case, no heatsinks and no fan. Just a screwdriver! Pictures of the scredriver are below. I wasn't sure if I would overheat and throttle in seconds but it turned out ok.

I only did the test for about 25 minutes just to see if I could pull off the Q3 test on a bare Pi and a screwdriver. All I did was hold the screwdriver end cap on the chip. I felt the heat slowly rise up the screwdriver and heat my hand up. As you can see from the pics the end of the screwdriver only makes partial contact around the edge and in the dead center. I think it would have run much cooler with a flatter screwdriver that has more direct contact on the chip.

I started the Q3 test under load and leveled off somewhere between 81-84C. It didn't overheat & downclock. Surprisingly the screwdriver does remove a lot of heat and you fingers in turn dissipate it from the screwdriver which allowed the Pi to run Q3 at very high temps. I think some grease, a flatter head, removing the chrome plating or all would have driven down well below the Flirc 2 with tape. Maybe even close to the top. I think the take away is the single most important thing is good contact with the SoC to dissipate the heat.

I will still use tape in certain scenarios but grease gets the nod on this one.

Of the 3 cases the BIQU performed the best but I prefer the look of the Flirc 2. The open case was the first one I owned and I don't know if there's much improvement. It's biggest drawback is it's loud which doesn't bother me except when it sits just right it vibrates and "rattles" but it's also the most affordable at around $10 US.

The Flirc 2 needs improvement, possible columns that contact the ethernet and memory chip. Also making them solid metal would help but it's a really nice looking case. It performed the worst and also was the most expensive at around $16 US.

The BIQU needs to improve the mounting holes/bracket so screws don't ground out on the bottom of the board. They could also widen the heatsink columns to cover more of the chip (it would run even cooler) and lastly add some external indicator lights would be great. With a few improvements it would be a perfect case and came around $12 US. It's cheap, cool and quiet.

quicksilver

@riverstorm wow this is a lot of interesting data! I'm shocked at how well the screwdriver performed. It makes me wonder what other household items could be used as a heatsink? (I feel like there is a YouTube channel opportunity in there somewhere)

Its interesting the results you got when testing GPU frequency. My Pi's GPU is stable at 505mhz, anything higher than that and eventually quake 3 will crash a few hours in. Surprisingly, the core frequency (GPU core) I am able to overclock to 560mhz and achieve stability. I might be able to push it a little higher but I eventually get crashes past 575mhz or so. I also have arm frequency set to 1350mhz, again I might be able to go a little higher but I don't see much reason to since I'm not really seeing major performance gains by boosting the CPU speed (extra N64 performance is my goal, which is also the reason the pi3b+ didn't interest me).

My pi enclosed in my super kintaro 9000 case with heatsink while running quake 3 test will top out at about 70°C (ambient temperature in my basement is 17.5°C). I have a small case fan I could also use but haven't installed it yet since my pi hasn't come close to throttling, and because I prefer to use passive cooling if able.

Definitely post any other tests you run. Your findings are very intriguing.

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