As far as I understand it, it's a hardware component of the 'clock' type that isn't present on revisions later than 20XX.
For what it's worth, after testing several consoles (mainly CECH L / Sherwood models, which I'm focusing on), it appears that not all of them necessarily support the same XDR timings, and some even refuse to go beyond stock settings (24). The results therefore seem to vary depending on the individual units.
After working on several modded CECHL units, I eventually came across one whose RSX was able to run stably at 750 MHz / 1000 MHz.
For reference, I stabilized it at 1.25V. This unit came with its original Fujitsu HDD (2009-09) and had the particularity of refusing any XDR timing modifications (unfortunately). I also encountered another case where a machine only accepted an improvement of the tRC from 24 to 23.
Additionally, as is often the case with these models, any attempt to raise the voltage beyond this limit results in an immediate hard shutdown as soon as the RSX comes under load.
Another CECHL was stabilized at 700 MHz (with 1.225V). This one, however, accepted the XDR RAM timing modification down to 21 without any issue (the maximum stable limit mentioned on GitHub). Its particularity was that it did not hard shutdown beyond 1.25V, but its RSX simply could not stabilize beyond the previously mentioned frequency limit.
At this stage, I can reasonably suggest that there are probably two types of CECHL boards — even though the motherboards are technically the same model: those that enforce a voltage limit, and those that allow it.
I was unable to find the Sherwood command to disable Spread Spectrum (if I understood correctly, w 3122 00 for Mullion). I would have been curious to see whether disabling it could have provided some additional headroom regarding these abrupt shutdowns.
By the way, on all the machines tested (roughly ten units), overclocking the CELL to 3.9 GHz only required 1V. Interestingly, going below this value prevents the machine from booting at all, whether overclocked or not.
I also carried out an overclocking test at 4.5 GHz (the only other clock value aligned with the PLL settings) using a voltage value of FF. It worked surprisingly well, but as already mentioned, the limitation of a certain memory bus causes audio desynchronization — and likely many other issues I did not take the time to investigate further.
From what I have been able to understand so far, the practical upper limit for PS3 CELL overclocking would be around 4.2 GHz.
I will probably continue experimenting on the Slim 20XX models next.
I am sharing these modest observations in the hope that they may be useful to the community. Once again, I would like to express my thanks and congratulations to everyone who made it possible for us to explore this playground.
Interesting PS3 CELL OC finding on a CECH-20XX.
I initially overclocked the CELL using:
The goal was to avoid clock desynchronization issues by keeping proper clock relationships instead of using some of the more aggressive presets.
System appeared stable:
- games stable
- no freezes
- no obvious crashes
However, both Crysis 3 and Final Fantasy XIII showed severe audio desync/stuttering during video cutscenes while gameplay itself remained perfectly fine.
After testing, lowering the CELL one step down to:
completely fixed the issue.
Interesting part:
this suggests some PS3s can appear stable at 3.9 GHz while still exhibiting subtle SPU/audio/video decoding instability before hard crashes occur.
It also suggests that the stable CELL OC rules documented in the GitHub repo — largely based on CECHA behavior — may not universally apply to all later models.
At least on this CECH-20XX, 02 11 seems to be the actual stable point while 04 1B was only "gameplay stable".
Additional note regarding the same CECH-20XX from my previous post.
Out of curiosity, I tested an extreme CELL configuration using:
- FF voltage
- ~5.3 GHz effective CELL clock
Surprisingly, the console actually booted without immediate crashes or shutdowns, and I was even able to launch a Crysis 3 game session.
However, as expected, clock synchronization was completely broken.
Still interesting to see how far the hardware can be pushed before completely refusing to boot.
