Flycast forcing reboot; time taken to do so dependant on overclock settings

stevas

Details:

Pi Model: 4
Power Supply used: official Pi4
RetroPie Version Used: 4.6.1
Built From: retropie-buster-4.6-rpi4.img
USB Devices connected: 64gb thumb drive
Controller used: M30 8bitdo
Error messages received: none (Pi reboots)
Emulator: lr-flycast

How to replicate the problem:

Setting overclock to anything even remotely aggressive such as:
over_voltage=6
h264_freq=750
isp_freq=750
v3d_freq=800+
arm_freq=2000+

Results in a self reboot occurring more rapidly:

Boot the game capcom Vs snk
Go to training mode
Select the fourth stage (truck accident)
Select normal speed
Select the default characters and groove (capcom)
wait (i.e. don't actually even bother playing)

Notes:

How long I'm waiting for the pi to reboot depends on the OC values I set. With particularly aggressive numbers (v3d=830, arm=2050), I might not even get to the actual fighting...

This may well be down to some core options I have set for that emulator, which I've yet to determine.

If OCing is causing this, how is it that any changes in OC settings seems to have zero effect on the framerate for this game (up to the point it crashes, I mean)?

mitu

How are you determining there's a memory leak and not your overclocking settings causing this ?

dankcushions

@stevas said in So this Flycast memory leak thing, then...:

If OCing is causing this, how is it that any changes in OC settings seems to have zero effect on the framerate for this game (up to the point it crashes, I mean)?

OCing will only speed up the framerate if the components you are overclocking are a) actually the bottleneck for that emulator and/or b) aren't throttling down because of too high temps/not enough volts. typically the pis meagre system bandwidth is the bottleneck in emulation, which only a RAM/core overclock might help, really. i have no idea why you would be overclocking stuff like h264_freq and isp_freq, in any case... nothing to do with emulation.

OCing can certainly affect stability and cause crashes, so the first step is to remove all overclocks and return to defaults - we'd need to take a look at your /boot/config.txt to confirm that. a memory leak should not be affected by them.

and you should also post the verbose log and relevant config files. if your overclock wasn't unstable it shouldn't cause a reboot, so once you've got rid of it and recreated the problem, you should be able to get at the log.

barbudreadmon

see my comment at https://retropie.org.uk/forum/post/228172

stevas

Apologies mitu, I incorrectly thought I was stumbling on an existing memory leak issue, but I been set straight on that mistake and edited accordingly.

Some other observations:
As far as I can see when this happens I'm at no more than 60 degrees?
I've tried two different PSU here (one of which is official).
This only happens with flycast so far in my testing (megadrive and SNES seem fine). It's related to the OC settings, I can practically control how long it takes to happen with those.

Should I just plain not be setting stuff like h264 and ISP? Sorry, I'm just faffing around with stuff here.

mitu

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

It's related to the OC settings, I can practically control how long it takes to happen with those.

Then you should lower or disable the overclock altogether if you want a stable system.

Should I just plain not be setting stuff like h264 and ISP? Sorry, I'm just faffing around with stuff here.

I don't think they'll be helpful if you just want to overclock the GPU/CPU.

stevas

Yeah, I'm just experimenting with what others have used in the deathsmiles mame thread.

I am well confused now, tho. I thought it was now advised to avoid using the gpu_freq setting and use individual override settings (such as isp and h264) as per:
It is recommended when overclocking to use the individual frequency settings (isp_freq, v3d_freq etc) rather than gpu_freq, as since it attempts to set core_freq (which cannot be changed on the Pi 4), it is not likely to have the desired effect.

Could someone direct me to what actual safe overclock settings are?

Also, how could I tell if I had an early board with dodgy components?

mitu

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

Could someone direct me to what actual safe overclock settings are?

I don't think there are 100% 'safe' settings - it depends on the board. You'll need to experiment with different values and test each configuration until you reach a stable configuration.

Also, how could I tell if I had an early board with dodgy components?

Which components ?

barbudreadmon

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

Also, how could I tell if I had an early board with dodgy components?

https://www.cnx-software.com/2020/02/24/raspberry-pi-4-rev-1-2-fixes-usb-c-power-issues-improves-sd-card-resilience/

quicksilver

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

It is recommended when overclocking to use the individual frequency settings (isp_freq, v3d_freq etc) rather than gpu_freq, as since it attempts to set core_freq (which cannot be changed on the Pi 4), it is not likely to have the desired effect.
Could someone direct me to what actual safe overclock settings are?
Also, how could I tell if I had an early board with dodgy components?

The ISP block of the GPU is for image sensor processing and h264 is for video decoding. These are not used with emulation and overclocking them is pointless when used with retropie.

You are not guaranteed any overclock on your pi. Overclocking is by definition pushing the component past it's guaranteed safe operating frequency. If your pi 4 works as expected at stock frequencies then your pi is not defective. If every pi was guaranteed to run at an overclocked frequency then they would just ship them that way from the factory. You might want to Google "silicon lottery" to see what I'm talking about.

stevas

Thanks.
As suspected, I have a cu3111.
But it is my understanding that this wouldn't mean anything (with regards this topic) while I'm using an official PSU anyway?

quicksilver

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

Thanks.
As suspected, I have a cu3111.
But it is my understanding that this wouldn't mean anything (with regards this topic) while I'm using an official PSU anyway?

Correct, that issue only effected people trying to use the high quality e-marked usbc adapters.

stevas

@quicksilver
Thanks for clarifying. I thought I'd seen someone advise me to tone the OC down to "safe" levels somewhere though.

mitu

@barbudreadmon said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

https://www.cnx-software.com/2020/02/24/raspberry-pi-4-rev-1-2-fixes-usb-c-power-issues-improves-sd-card-resilience/

That problem is related to the non-PD compliant USB-C power port on the initial revision - it just means it's not going to work with all USB-C power adapters. It's not singular to the Pi - the Nintendo Switch has the same behavior and other SBC's have also the same design (NanoPi M2 models for instance). There's no issue if you're using an official RPI power adapter and it doesn't affect performance. I wouldn't call it dodgy, just sloppy engineering.

The other - major - issue that I'm aware of regarding the Pi4 was the high temps noticed after the initial release. That has been corrected/improved through a firmware/eeprom update some time in Sept last year (if I remember correctly).

EDIT: there were also some improvements in the CPU dynamic frequency switching (DVFS) around the end of 2019/beginning of 2020 (?), which also improved the thermal output of the Pi and temporarily disabled the ability to overclock the CPU/GPU, but the limitation was corrected via firmware updates.

quicksilver

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

@quicksilver
Thanks for clarifying. I thought I'd seen someone advise me to tone the OC down to "safe" levels somewhere though.

What a "safe level" is will vary from pi to pi. Every pi is different, just like ever person on the planet is different. Just because Usain Bolt can run 27mph doesn't mean I can. To find your max safe overclock takes a lot of time and experimentation. Check out the official RetroPie documentation for overclocking and it answers a lot of these questions.

stevas

@quicksilver
Well... Yeah. But it feels like I've found a safe OC for everything else but flycast, which doesn't like any form of OC at all.

And I'm still unclear on whether I should use gpu_freq or not.

Edit
To be clear: I just thought I'd seen someone refer to a safe level of overclocking, and my mind immediately went to "oh, there's an agreed level of overclocking by the community"; i.e. not recommended necessarily by the manufacturer etc, but something you should generally get away with - if you get me?

stevas

@mitu said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

Could someone direct me to what actual safe overclock settings are?

I don't think there are 100% 'safe' settings - it depends on the board. You'll need to experiment with different values and test each configuration until you reach a stable configuration.

Also, how could I tell if I had an early board with dodgy components?

Which components ?

Sorry, thread is moving quicker than I anticipated!
I was referring to the "faulty" comment here?

Gah, which of course I forgot to paste:
https://retropie.org.uk/forum/post/228172

quicksilver

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

@quicksilver
Well... Yeah. But it feels like I've found a safe OC for everything else but flycast, which doesn't like any form of OC at all.

A marginally stable overclock is still an unstable overclock. You aren't likely to cause any damage to your pi this way but over time you are risking corrupting sd card.

And I'm still unclear on whether I should use gpu_freq or not.

GPU freq should be fine, it just will not affect core freq like it used to. Or to simplify things just overclock v3d freq because we don't care about the other blocks of the GPU anyway.

dankcushions

@stevas said in Flycast forcing reboot; time taken to do so dependant on overclock settings:

@quicksilver
Well... Yeah. But it feels like I've found a safe OC for everything else but flycast, which doesn't like any form of OC at all.

it makes sense that a sophisticated 3d emulator, likely hammering the gpu, cpu, system bus and so on, is going to be more sensitive to instability than a simpler 2d one.

To be clear: I just thought I'd seen someone refer to a safe level of overclocking, and my mind immediately went to "oh, there's an agreed level of overclocking by the community"; i.e. not recommended necessarily by the manufacturer etc, but something you should generally get away with - if you get me?

anecdotally, the "safe" overclocking guides for pi3, including the ones on our wiki, are not safe at all, IMO. they certainly weren't close to the settings i was able to get away with my pi3. ETA prime's insane overclocking guide must have been the source of 100s of "why is my retropie crashing?!" support requests...

stevas

@quicksilver

Many thanks, I will remove gpu_freq going forward and just use v3d and arm now.