Flycast forcing reboot; time taken to do so dependant on overclock settings
-
see my comment at https://retropie.org.uk/forum/post/228172
-
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.
-
@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.
-
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?
-
@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 ?
-
@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?
-
@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.
-
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? -
@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.
-
@quicksilver
Thanks for clarifying. I thought I'd seen someone advise me to tone the OC down to "safe" levels somewhere though. -
@barbudreadmon said in Flycast forcing reboot; time taken to do so dependant on overclock settings:
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.
-
@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.
-
@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? -
@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 -
@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.
-
@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...
-
Many thanks, I will remove gpu_freq going forward and just use v3d and arm now.
-
Heh, yeah, and - phew (right?) - I've been one of them...
Anyway, think we're done here.
Also, once again, you're all fine people, and much appreciated for setting me straight.
Won't stop me trying to break this thing tho.
-
@stevas To be clear - and I've tried not to comment here as @quicksilver and @dankcushions have more experience in overclocking the Pi than I would have - the process to try to find out a stable overclocking for your Pi should still be the same.
The best help I found here was from a post from @quicksilver 2 years ago: https://retropie.org.uk/forum/topic/17032/stresstest-a-fanless-overclocked-pi-3-b-no?_=1593105029442
Probably Quake 3 is no longer a good stress test for the Pi 4 (on mine it never really made its CPU or even temperature rise a lot), but it still stands. Change one parameter at a time, then stress test for a while. Then readjust, adding more or less parameters.
I never overclocked my Pi 3 nor 3B as it was never really stable either. Start with core, then feel free to change others. Or start with others and keep core. Test and iterate. I spent the better part of a weekend on mine (and then reflashed the card in case some of the hangs would have corrupted it), and after a few weeks that wasn't stable so I took core down a bit more.
What I ended up stress testing with was Quake 3, per that post's suggestion, but afterwards lr-yabasanshiro, lr-flycast and lr-mame2016 running one of those Cave shooters from the previous thread, as it did seem to push the CPU quite a bit. I left them on for an hour or more in the attract modes. I did have a fan for some of them, when I saw the temperatures rising fast - lr-yabasanshiro was the biggest offender there, high-cpu all around.
Best of luck.
-
Dude, thanks; I'll probably have a go at the cave stuff on 2016 now... Yeah, it does often feel like I need good fortune with this stuff...
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.