cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4

[akamming]

@BuZz said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

@akamming I doubt you have a stable overclock.

Both pi's are stable! with these settings there fine. spend quite some time getting the correct values. If i increase the speeds they indeed become instable. But so far i have not seen any instability with these settings.

The CPUs throttle / downclock based on temperature also. Maybe one is too warm.

Aha .. wasn't aware of this. tx. Just checked. The one which stays at 600 is indeed a bit warmer. Not very alarming though: in the last month average of around 56 celcius with the highest peak at 61 degrees celsius. The other one averages around 49 degrees celcius. Might explain the difference. I will run some testing on a lower temperature. Where can i find documentation on how this mechanism works?

You're probably going to shorten the life too.

Yeah might be. I don't think a lot since temperature is not too high, but i am not too worried. I have 2 year warranty and with these settings the warranty bit is not set... ;-)

[BuZz]

@akamming said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

Both pi's are stable!

How did you come to this conclusion?

[VictimRLSH]

I may be oversimplifying things here, but it sounds like a classic case of Silicon Lottery. It's like opening a bag of Lay's, no two chips are the same.

ThreadX in the GPU could be throttling your speed for a reason that is not readily apparent no matter what your kernal has to say about it, and you won't really be able to tell why either.

[akamming]

@BuZz said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

How did you come to this conclusion?

One is in use as a desktop and as my file server (and i occasionally play games on them, so also retropie installed). The other one is in a self made arcade cabinet. I never reboot them (will be at least a month ago) and they don't give me any problems.

The good news is btw that i found the cause. Running on a lower temperature had no effect, but i did found a difference in the 2 pi's: in the setting " /sys/devices/system/cpu/cpufreq/ondemand/up_threshold". On the well performing pi it reports 50. On the less well performing pi this is set to 95. When i change it to 50 as well the behaviour of both pi's are exactly the same again (v3d clock goes to 800 as well in ondemand mode)

Still weird that this difference in default values exists. both are stock raspian installs with the default settings (apart from the overclock settings above) and a manual installation (https://retropie.org.uk/docs/Manual-Installation/) of retropie. but it works now, so i'm happy...

[BuZz]

@akamming Sorry but that doesn't mean you have a stable overclock. You need to do something like loading all 4 cores and GPU.

Many issues arise due to overclocking anyway, when users are sure they have a stable overclock.

I dont recommend overclocking as much as you're doing.

[akamming]

@BuZz said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

@akamming Sorry but that doesn't mean you have a stable overclock. You need to do something like loading all 4 cores and GPU.

The most "stress" thing i did was using the standard stress tool 3 cpu's while in parallel playing outrun 2006 for about an hour (and then i got tired of it) some time ago. this works fine. maybe i shold be testing for a longer time.. if someone knows a good test tool in which i can stress all cpu's, memory, gpu and io parallel pls let me know. It is a test i really want to do...

Many issues arise due to overclocking anyway, when users are sure they have a stable overclock.

totally agree here. with stable i mean it is stable in my usage. And since i'm overclocking. The 1st thing i always do in case of issues is retest without overclock 1st to rule out the overclock effect on the issue. (But as stated, currently don't have any issues...so currently not applicable ;-))

I dont recommend overclocking as much as you're doing.

understand this as well, but this is personal preference i would say.... i don't mind getting extra performance on the risk of extra issues...

[pjft]

@akamming I found that between mame2016 playing some recent CAVE games (Ibara, or similarly taxing ones) and yabasanshiro playing something, both for an extended period, would usually use the 4 CPUs and the GPU as well.

But, no joking, you can also just install Super Flappy Birds and play it for 10/15 mins, with the default Video Threaded options. The pi will likely reboot at some point when you have an unstable overclock :)

I take it you're playing the PSP version of OutRun?

[akamming]

@pjft said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

@akamming I found that between mame2016 playing some recent CAVE games (Ibara, or similarly taxing ones) and yabasanshiro playing something, both for an extended period, would usually use the 4 CPUs and the GPU as well.

But, no joking, you can also just install Super Flappy Birds and play it for 10/15 mins, with the default Video Threaded options. The pi will likely reboot at some point when you have an unstable overclock :)

a tx for the tip. Super Flappy Birds is installed and stable. Never done it for an hour though. Maybe will try it some day.

I take it you're playing the PSP version of OutRun?

Yep

[akamming]

@pjft said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

But, no joking, you can also just install Super Flappy Birds and play it for 10/15 mins, with the default Video Threaded options. The pi will likely reboot at some point when you have an unstable overclock :)

Haha this is a nice test!

You don't even have to play the game. Just being on the start screen makes the pi including GPU work hard.... ;-) So i left it on as of yesterday see what would happen.

it did not use all 4 cpu cores (only 1,5 on average), so i added a "stress -c 3" in the background. This was the 1st time my passive cooling was not enough. System started throttling down the clock speeds after about one and a half hour.

It remained stable all 24 hours, so I now know I have a stable overclock. Only need to add active cooling if i want to be using all processing power for more then one and a half hour…

Tx for the tip!

(PS would be curious to know why super flappy birds needs all this processing power. even within the throttled state and the stress process in the background it still runs very smoothly)

[Riverstorm]

From his post I wouldn't question the stability per se as that doesn't seem to be the issue but more performance related since he has no reboots, lockups or corruption. I would expect both Pi's to perform similar based on the identical overclock settings, for the same game, unless they are radically different setups. Basically the CPU load would be similar which triggers the dynamic clocking frequencies depending on the settings. You could tweak a few things though.

From what you're saying it seems it ignores up_threshold when set to performance but honors it with on-demand. I'm surprised the Pi with the up_threshold set to 95 averaged warmer temps but that could environmental. I would be leery if it throttled during your 24 hour stress test. To be sure it's stable at those speeds it seems you would need to retest with active cooling so it can keep the overclock speeds up and not throttled much slower.

On a Pi 4 you can't change the core_freq when using gpu_freq, in fact it's unsupported/not recommended, it will try though which will most likely give you undesired results. I found overclocking unstable, after a certain level, when using it on a Pi 4 on the Pi 3 it's fine.

I was able to easily achieve a stable 2.1GHz (heavily tested across days) once I removed gpu_freq. I was not able to achieve a stable overclock at 2.147 (the theoretical max with the latest firmware) but 2.1 was no problem. I don't know but I would assume the v3d_freq will override the gpu_freq since it is in direct conflict with the more precise setting vs. the blanket setting but I would just remove it.

The Pi with an up_threshold of 50 is triggering at a lower threshold. I would guess the game is hovering between 50 and 95 hence the big difference between the Pi's numbers.

You could also play around with sampling_down_factor and sampling_rate as it may drop and nail the CPU very rapidly with certain games. You could set it higher to allow a bit more headroom before dropping out of turbo. You'll have to play around with the settings to find what works best for your setup. Also the on-demand governor has no effect if you have no overclock settings. There's also several _min settings you can use to fine tune.

The other thing worth testing when overclocking, that sounds contrary, is idling your overclock. I found certain overclocks will lockup when idling or doing simple attract mode loops in the most basic arcade games.

If you're going to overclock that high you definitely need sufficient cooling. While not as practical as a closed portable case the Ice Tower setups cool far and away better than any case I've tried from a open negative space case, Flirq, BIQU, Argon One, any fan/heatsink combos, etc. etc. CPUBurn even gives the Argon One a run for it's money with it's direct contact case/fan combo. The Flirq and BIQU just can't keep up. I setup a small house fan to blow directly on those cases during CPUBurn testing but eventually they do throttle without the fan it was much quicker.

I originally had my over_voltage set to 5 but found if the power isn't "smooth" at your location it may crash. I haven't had a single crash at 6 and it shouldn't void the warranty unless used in conjunction with force_turbo, the heat jump is marginal.

Traditionally I seem to have better luck with UK built boards vs. China when overclocking (around a dozen total) but the UK Pi 4 is savage at an almost 29% increase on the arm_freq and 41% on the v3d_freq! I really beat the hell out of a few boards and they are well built for sure. The UK is doing it right! ;)

[mitu]

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

I originally had my over_voltage set to 5 but found if the power isn't "smooth" at your location it may crash. I haven't had a single crash at 6 and it shouldn't void the warranty unless used in conjunction with force_turbo, the heat jump is marginal.

The Pi4 doesn't have a 'warranty' bit, any over-clocking configuration is not recorded anymore - as it was on previous models when force_turbo/over_voltage were set.

[Riverstorm]

@mitu said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

The Pi4 doesn't have a 'warranty' bit, any over-clocking configuration is not recorded anymore - as it was on previous models when force_turbo/over_voltage were set.

Hey @mitu ok, thanks for the information. Is that a recent firmware change or does their website need an update? This is what they have current and several references on the forums to the warranty bit, revision tables for all the versions, etc. on the Pi 4 as recent as April. I couldn't find anything different from what is posted below.

NOTE: Setting any overclocking parameters to values other than those used by raspi-config may set a permanent bit within the SoC, making it possible to detect that your Pi has been overclocked. The specific circumstances where the overclock bit is set are if force_turbo is set to 1 and any of the over_voltage_ options are set to a value > 0. See the blog post on Turbo Mode for more information. Pi 4 overclocking options may be subject to change in the future.*

Hi there i just overlocked my pi 4 via the config and overlolted it to 6.
How do i check the warranty bit and is the warranty now voided?
That's c03112 4B 1.2 4GB Sony UK

It isn't. The revision would show as 2c03112 if the warranty void bit was set.

[mitu]

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

Hey @mitu ok, thanks for the information. Is that a recent firmware change or does their website need an update? This is what they have current and several references on the forums to the warranty bit, revision tables for all the versions, etc. on the Pi 4 as recent as April. I couldn't find anything different from what is posted below.

See this post by a RPT engineer:

The "warranty" bit was added as a way of pacifying suppliers who were nervous that allowing overclock may result in a large number of dead Pi's being returned. But since the first Pi was released we've never seen a Pi that appears to have died through overclocking.

We don't even set the bit on Pi 4, so feel free to experiment. Obviously too high an overclock may make a Pi unstable and crash.
Don't do it on a Pi with valuable data on it without a backup.

The benefits of overclocking newer Pi models is much less than on the original Pi 1, as the default speed is so much greater.

[akamming]

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

tx for all the useful info. here's a reaction.

From what you're saying it seems it ignores up_threshold when set to performance but honors it with on-demand.

Yep, and that's expected behaviour and the reason why i used runcommand to set the governer to performance. I noticed btw that performance is slightly better whith the governance set to performance. Although both pi's now act the same (the difference was the up_treshold setting). They both sometime dropped the v3d clock back to 600. Where in performance it stays at 815. and apparently this is need for n64 and psp emulation, cause i have a slightly better fps when the clock runs a 815. and since i now don't use the ondemand governer when running the emulators, i don't have to play around with stuff like sampling rate, sampling down factor, etc...

The other thing worth testing when overclocking, that sounds contrary, is idling your overclock. I found certain overclocks will lockup when idling or doing simple attract mode loops in the most basic arcade games.

i did not do a specific test, but since the pi is built into an arcade cabinet, most of it's time it's idling without issues (i would expect so, cause the the clock drops down to normal rates when the cpu/gpu is not used). Do you have a specific game in mind which crashes in attract mode with unstable overclock? I haven't seen this behaviour yet…

I was able to easily achieve a stable 2.1GHz (heavily tested across days) once I removed gpu_freq. I was not able to achieve a stable overclock at 2.147 (the theoretical max with the latest firmware) but 2.1 was no problem. I don't know but I would assume the v3d_freq will override the gpu_freq since it is in direct conflict with the more precise setting vs. the blanket setting but I would just remove it.

2.1 GHz is almost stable, but sometimes gives freezes or reboots, so i went down to 2.0Ghz (no problems since). according to the docs i found gpu_freq should not be set on a pi 4, cause this might make it unbootable, but i accidentally did it and found out that on a pi4 this sets the default clock speeds for h264, isp van v3d freqs. which can be overruled by the indivudeal settings (so that's why i have gpu_freq=750, v3d_freq=815). i use hdmi_enable_4kp60 to boost the core freq.

i know i need more cooling if my goal was to use as much processing power as possible. however i don't like moving parts so try to avoid them. And with passive cooling, even with overclock temperatures never reach the point where the system starts to throttle when playing retro games.

[akamming]

@mitu said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

Hey @mitu ok, thanks for the information. Is that a recent firmware change or does their website need an update? This is what they have current and several references on the forums to the warranty bit, revision tables for all the versions, etc. on the Pi 4 as recent as April. I couldn't find anything different from what is posted below.

See this post by a RPT engineer:

The "warranty" bit was added as a way of pacifying suppliers who were nervous that allowing overclock may result in a large number of dead Pi's being returned. But since the first Pi was released we've never seen a Pi that appears to have died through overclocking.

We don't even set the bit on Pi 4, so feel free to experiment. Obviously too high an overclock may make a Pi unstable and crash.
Don't do it on a Pi with valuable data on it without a backup.

The benefits of overclocking newer Pi models is much less than on the original Pi 1, as the default speed is so much greater.

That's interesting! this would imply i could try to overclock more by increasing the voltage without reducing the lifespan or limiting the warranty. Has anyone alread tried if this is really the case? (set force_turbo and over_voltage>6 and then check the warranty bit?)

[Riverstorm]

@mitu - That's very interesting, that kind of changes the ball game a little and the thinking on overclocking. It's only a small bump in power going to 8 (the max value) using force_turbo but it may help stabilize a slightly higher overclock.

I'm a little surprised as it implies for the most part you can't damage the Pi or warranty from overclocking but I suppose they still have controls in place with a cap at 1.4V. If you can zip the temp straight up fast enough through high voltage maybe but I don't know. I'll have to let that soak in as that's just interesting information.

On the inverse you can set a bit to lock the Pi so you can't overvolt at all.

It's similar to Intel's K line of chips. You basically pay a higher price I suspect to offset the cost to the company for a higher burn percentage on unlocked chips.

It's not much different than Alienware or Falcon that do a 3 day burn-in test that voids even the Intel warranty but they cover it for the life and then an additional year or two. Falcon's come at a very premium price though with those custom paint jobs.

Of this beauty a Silverdraft Demon coming in at a hefty $49,500! You need this for proper MAME gaming! ;)

@akamming - I never worried much about shortening the lifespan of the Pi. I've pretty much have "junked" every generation of Pi long before it ever had a chance to burn out.

I honestly think as hard as I've been running my Pi 4's they will still run for years and years with a proper cooling solution. The testing is such a small part of their life. If you keep it cool enough I would even venture it will last just as long. Heat aside I have no idea if slightly higher voltage through capacitors and other components shortens their life.

One thing I found the hard way is always overclock test with a backup image. Each lockup slowly corrupts the image, even though it still boots fine. I thought the image was clean until I used pishrink. It will not compress down properly with any errors in the image file structure. In fact it tries to correct them and fails more times than not.

With performance it's going to bump to the highest frequency based on the up_threshold within the limits of the min/max values and hold it there based on the sampling_rate.

On-demand will start adjusting the frequency based on the up_threshold and load (estimation) but within the limits of the min/max values and hold it there based on the sampling_rate.

powersave will operate on the opposite end making frequency adjustments based on the min values set.

It makes sense what you're saying about better performance. Basically performance will peg at the set frequency but on-demand will bump it up and down based on "load sampling" and not necessarily set it to the max frequency.

If you're Pi is in one location I think you could build a sufficient passive solution for higher overclocks. It might be a bit larger than average but it wouldn't have any moving parts!

[mitu]

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

Of this beauty a Silverdraft Demon coming in at a hefty $49,500! You need this for proper MAME gaming! ;)

Actually, if you closely look at the Q&A section, they don't recommend it for gaming. Plus, only 198Gb memory at this price and no SD card slot ? C'mon.

We would not suggest this super high end gaming workstation for gaming. As the processor and multiple video cards of this type are not geared toward gaming.

[Riverstorm]

@mitu - Well shoot! No gaming and you would think you could get a SD card slot (or dare I say, two!) for that price. I knew it was to good to be true at 50 grand.

198Gb...it's impressive, that's almost as much RAM as our boot drives on M.2 SSD's.

Kind of off topic but that's the other thing Intel is doing that I don't care for are the newer KF chips. Basically they have the unlocked multiplier (K--as always) but the (F) means no integrated graphics. There's nothing like having a way to selling defunct chips.

They failed QC for one reason or another with the integrated graphics but they still sell them at almost the same premium price as the regular K chips that have integrated graphics.

Companies like Dell are picking them up (I'm sure at a discount) and re-purposing them in their Alienware line.

Anyway a minor rant for an otherwise great gaming rig!

[Clyde]

@Riverstorm said in cpu governer leaves v3d only at 600mhz at one pi4 while going tot 815mhz on another pi4:

Of this beauty a Silverdraft Demon coming in at a hefty $49,500! You need this for proper MAME gaming! ;)

You could get approx. 1,400 2GB Pi 4 with collectively 2,800 GB of RAM for that, or 660 8GB Pi 4 with 5,280 GB total RAM, and then build a RPi cluster:

(Yes, there are newer videos of RPi clusters, but this is the most beautiful that I know of. 🤩 )

That said, actually I would very much like to see how such a cluster would fare against the Silverdraft Demon. 👹

[Riverstorm]

You could get approx. 1,400 2GB Pi 4 with collectively 2,800 GB of RAM for that, or 660 8GB Pi 4 with 5,280 GB total RAM, and then build a RPi cluster:

Whew, that's going to take up it's fair share of space for the Pi's alone. Minus racks, cooling, power, etc. for the Pi's I used the bigger number just for fun.

Pi dimensions - 56.5 x 85.6 x 11 mm = 53.2004 cm^3

53.2004 cm^3 x 1400 = 74,480.56 cm^3

So if those calculations are correct you're going to need 74,481 cubic centimeters which is roughly 745 cubic meters for the Pi's alone. You're gonna need a fair sized room!

OR

The Silverdraft Demon - 43.18 x 43.18 x 27.94 cm