PS3 Project RSX Boost: Overclock your Retail PS3 RSX Speeds (ps3 cfw only)

[Tanzu15]

Besides drop in FPS none that we have noticed. There were some debug units that were clocked lower listed on the dev wiki. Some of them had VID binned silicon (more efficient) with higher clocking potential, but were ran under.

We havent gone lower than the 400 that was already in MFW builder, but now that we know how to generate the LV1 and add the entry to the combox, we could go lower and see where the underclocking limit is.

I nearly bricked my 2501a this weekend. There were ZERO warning signs as 950 VRAM and then it was completly frozen even in safe mode at 975. That's how quick it can go from stable to damn near full soft-brick, even with 25MHz increments.

I was able to recover it by using SYSCON UART to edit the fantable's 1st step fan% to 100% (0x33 to 0xff). After being off and cooled to room temp there was a brief time that it seems stable. Then artifacts begin appearing (pin pricks of light) and become more numerous as it heats up, and finally it froze at about 60% of the 1st part of the update, where it loads before restarting to install. After booting fan to 100% it kept it cool long enough to finish the update, but there were a few artifacts on screen making it hairy.

So PROCEED WITH EXTREEM CAUTION. I do have a teensy, doesnt mean I want to solder all them wires!

What month of manufacture is that 2501A?

 

[RIP-Felix]

July/2010 IIRC, but I dont have the spreadsheet in front of me ATM. I have 74 consoles worth of data in it so far. Am seeing some trends. I'll release it when I'm satisfied I can draw some conclusions.

But so far, SONY fabricated 40nm RSXs clock the higest. TSMC clock lower on average. I still need to do the actual statistics to show the difference and see if it's significant, but that's what it preliminarily looks like.

I need to go back over everyones posts looking for date codes, but ATP I do not think it's higly correlated. The lot numbers could indicate better which batches were particularly better. Date codes would get you to the general time frame, but not the specific fab that had the better batch. So even if there is a correlation between date code and clocks, there would be a more direct correlation between lot number. If you see what I mean.

 

[Tanzu15]

July/2010 IIRC, but I dont have the spreadsheet in front of me ATM. I have 74 consoles worth of data in it so far. Am seeing some trends. I'll release it when I'm satisfied I can draw some conclusions.

But so far, SONY fabricated 40nm RSXs clock the higest. TSMC clock lower on average. I still need to do the actual statistics to show the difference and see if it's significant, but that's what it preliminarily looks like.

I need to go back over everyones posts looking for date codes, but ATP I do not think it's higly correlated. The lot numbers could indicate better which batches were particularly better. Date codes would get you to the general time frame, but not the specific fab that had the better batch. So even if there is a correlation between date code and clocks, there would be a more direct correlation between lot number. If you see what I mean.

Well one of my 2501A is July as well. And will you look at that, 975 is not possible either. Only 950 is possible. I have like 7 PS3s. And anything from august 2010 and going backwards cannot do high clocks. Anything from September and on has some potential. But so far only my December and January's can do 850 and 900 on the core and 975 on memory fully stable. I've been binning them.

 

[RIP-Felix]

If you would please post the Lv1 string, date codes, uptime, and model number of each console (and full RSX SKU if you cleaned paste and got that), that would help.

 

[Tanzu15]

If you would please post the Lv1 string, date codes, uptime, and model number of each console (and full RSX SKU if you cleaned paste and got that), that would help.

One of my 300 day 2501B January does 850 core and 975 memory. My other 2501B January as well, does 900 core 975 memory fully stable for both, this one is 117 days. And the one I talked to you about in the DMs, that died cause of the dumb board flexing, was doing 900/950, could do 975 but hadn't tried it yet. That one was 6 days up time and December and was again 2501B.

 

[Ketxxx]

I think it's time I start making some OC firmwares, I have ps3mfw builder 0.2.1 mod but I can't seem to find a checklist of things I need to make sure I build the firmware correctly for slim model PS3s. Anyone have a bullet list? I'll try to catch up on what I've missed once I've built some firmwares.

 

[cha0shacker]

EDIT:
Consider. The PS3 has technically the most powerful hardware in the 7th gen, but because of poor CELL optimization, many crossplatform games ran better on 360. A RSX OC doesn't make those games play significantly better anyway, so what we're talking about here is reducing the temps on a defective 90nm model to help stave off the YLOD. If it barely comes with a hit to performance that's a net benifit. And if we ever cam figure out the CPU OC, that will direcly target the #1 issue with PS3. The CPU bottleneck.

That's not really true. The GPU of the Xbox 360 is more powerful than the RSX. And the CPU is only more powerful once you invoke the SPEs in anything. The PPE is less powerfull than a single core of the Xenon in the Xbox 360.
In order to be more powerful than the Xbox 360 in practice you would need to help out the GPU and CPU with very specialized code that only works on SPEs. And even if you do that there is no guarantee you'll be able to match or surpass the 360s capabilities.

 

[Smugg]

I think it's time I start making some OC firmwares, I have ps3mfw builder 0.2.1 mod but I can't seem to find a checklist of things I need to make sure I build the firmware correctly for slim model PS3s. Anyone have a bullet list? I'll try to catch up on what I've missed once I've built some firmwares.

Her you go. MAKE SURE you have Sign isolated modules and Sign self/sprx UNCHECKED OR YOU WILL BRICK YOUR CONSOLE, Im not sure if this matters but dont have a cd in the console either when you update firmware.

heres a video to help as well.

 

[Tanzu15]

Her you go. MAKE SURE you have Sign isolated modules and Sign self/sprx UNCHECKED OR YOU WILL BRICK YOUR CONSOLE, Im not sure if this matters but dont have a cd in the console either when you update firmware.

heres a video to help as well.

How do those options cause bricks?

 

[Ketxxx]

That's not really true. The GPU of the Xbox 360 is more powerful than the RSX. And the CPU is only more powerful once you invoke the SPEs in anything. The PPE is less powerfull than a single core of the Xenon in the Xbox 360.
In order to be more powerful than the Xbox 360 in practice you would need to help out the GPU and CPU with very specialized code that only works on SPEs. And even if you do that there is no guarantee you'll be able to match or surpass the 360s capabilities.

@cha0shacker Going a step further depending on the architectural design of the Cell (something I'm not fully familiar with) if it has a core arrangement like sharing one FPU between two "cores" that would make a single "module" much like Bulldozer did then the Cell is always going to be an anemic POS when it comes to floating point calculations so even trying to brute force the problem with raw clock speed will only alleviate the problem so much.

What I am familiar with on the Cell CPU however is the bandwidth, it's terrible, so more than looking to increase the Cell core frequency I'd be looking at overclocking the system memory frequency as I'd bet even at stock the CPU is heavily bottlenecked by the god awful bandwidth available to it. Doing that would probably also sidestep the problem of when you OC the Cell you also throw all the other bus frequencies out of whack. To successfully OC the Cell core frequency you would probably have to code PLL dividers, which would not be easy, at all.

It's also likely that just OCing the RSX memory will show large gains as 500MHz core frequency for the time was actually pretty damn high which is just one reason why I'm going to make some OC CFW myself people can try as I'm going to focus quite heavily on bandwidth limitations in games first to fully document memory frequency increases alone.

Well here is a problem, anyone know what this is all about? Happens with Evilnat 4.91 Beta9 and 4.90 final. If I can find out what the issue is I will update.

 

[cha0shacker]

@cha0shacker Going a step further depending on the architectural design of the Cell (something I'm not fully familiar with) if it has a core arrangement like sharing one FPU between two "cores" that would make a single "module" much like Bulldozer did then the Cell is always going to be an anemic POS when it comes to floating point calculations so even trying to brute force the problem with raw clock speed will only alleviate the problem so much.

What I am familiar with on the Cell CPU however is the bandwidth, it's terrible, so more than looking to increase the Cell core frequency I'd be looking at overclocking the system memory frequency as I'd bet even at stock the CPU is heavily bottlenecked by the god awful bandwidth available to it. Doing that would probably also sidestep the problem of when you OC the Cell you also throw all the other bus frequencies out of whack. To successfully OC the Cell core frequency you would probably have to code PLL dividers, which would not be easy, at all.

It's also likely that just OCing the RSX memory will show large gains as 500MHz core frequency for the time was actually pretty damn high which is just one reason why I'm going to make some OC CFW myself people can try as I'm going to focus quite heavily on bandwidth limitations in games first to fully document memory frequency increases alone.

That's not quite it. The Cell has quite a lot of bandwidth available (25.6GB/s) to it and floating point performance is actually one of its strong points. The big issue with it is its low general purpose performance. While it's clocked at 3.2GHz the main core is an in-order dual pipeline designe with around the performance of a single core Pentium 4 running at 2.8GHz. In addition to that there a few very nasty pipeline stalls you can run into if you don't know what you are doing further degrading the performance. If you want to stay with the bulldozer analogy: It's a single integer core with 9 FPUs with 8 of them not being part of the main core and not accepting common code.

The problem with the RSX is not its clock speed, is it's architecture. Curie was made to run a couple DirectX 9 pixel shaders in parallel fast. When it comes to more complex shaders it chockes due to not having any scheduler or reordering capabilities and the pixel pipelines are getting blocked when texturing is performed. The PC cards based on Curie all aged horribly compared to their ATI content as well.

 

[Smugg]

Well here is a problem, anyone know what this is all about? Happens with Evilnat 4.91 Beta9 and 4.90 final. If I can find out what the issue is I will update.

Go to settings in MFWBuilder on the far right, Add the PS3_Keys. There should be a folder in the program directory

 

[Mitsu™]

Well, my 2504A is completely clean now, time to OC it !... but I'm tired, it's pretty late here.

Btw, now that I have a "NMB-MAT BG1004-B045-P00" in hands, I am intrigued by its design.
Especially by this layer at the middle of the blades.

This is the only model of (PS3 slim) fan having this kind of design as far as I know. Is it supposed to be more efficient ?
I will do some tests.

Also, my 2504A is some degrees hotter than my two previous 2004B slims despite having a 40nm RSX, funny. One of the reasons is probably the (IMO) $hitty heatsink present in the 25XX models. ("$hitty" is maybe a little exaggerated)
Too bad that we cannot use those of the 20XX slims, they don't fit. :\
I confirm that the "EADP-220BB" PSU works perfectly fine in a 25XX.

 

[Tanzu15]

Well, my 2504A is completely clean now, time to OC it !... but I'm tired, it's pretty late here.

Btw, now that I have a "NMB-MAT BG1004-B045-P00" in hands, I am intrigued by its design.
Especially by this layer at the middle of the blades.
View attachment 43166
This is the only model of (PS3 slim) fan having this kind of design as far as I know. Is it supposed to be more efficient ?
I will do some tests.

Also, my 2504A is some degrees hotter than my two previous 2004B slims despite having a 40nm RSX, funny. One of the reasons is probably the (IMO) $hitty heatsink present in the 25XX models. ("$hitty" is maybe a little exaggerated)
Too bad that we cannot use those of the 20XX slims, they don't fit. :\
By the way, I confirm that the "EADP-220BB" PSU works perfectly fine in a 25XX.

Man I'm curious about your overclocks

 

[Ketxxx]

That's not quite it. The Cell has quite a lot of bandwidth available (25.6GB/s) to it and floating point performance is actually one of its strong points. The big issue with it is its low general purpose performance. While it's clocked at 3.2GHz the main core is an in-order dual pipeline designe with around the performance of a single core Pentium 4 running at 2.8GHz. In addition to that there a few very nasty pipeline stalls you can run into if you don't know what you are doing further degrading the performance. If you want to stay with the bulldozer analogy: It's a single integer core with 9 FPUs with 8 of them not being part of the main core and not accepting common code.

The problem with the RSX is not its clock speed, is it's architecture. Curie was made to run a couple DirectX 9 pixel shaders in parallel fast. When it comes to more complex shaders it chockes due to not having any scheduler or reordering capabilities and the pixel pipelines are getting blocked when texturing is performed. The PC cards based on Curie all aged horribly compared to their ATI content as well.

Essentially the Cell can be considered to have the same horrible performance as P4s with net(nut)burst then, something along the lines of a Willamette lets say. 25.6GB\s bandwidth really isnt a lot by the time you have factored in overhead(s) (such as API used, latency, etc) and that figure is only specifically for the XDR system memory anyway, read\write operations are further crippled to 20\15GB\s (at best) depending if data is coming from or going to the Cell which is why I say CPU bandwidth is an issue and why an XDR OC would likely be rather helpful. Pipeline stalls will be a regular occurrence if shitty code is running on top of all of those other issues as well. Probably why so many games can dip under 20FPS, the worst Ive seen so far is with AC1, near the end of the game frame rate can bomb hard down to like 11-12FPS at critical times making things totally unplayable. Things like that never should have been allowed past QC but given the fairly open and large detailed maps that bandwidth is a good shout for being the cause on both CPU and RSX but I will stick my neck out and say more the CPU. Not entirely the CPUs fault though Ubisoft likely did nothing to optimise the code for the Cell.

As for the RSX, it not supporting anything like scheduling isnt a major issue up to a certain point you can create command lists to circumvent those problems quite nicely the problem arises when you keep piling things on the GPU without any mitigation code to take into account the GPU having more limited capabilities. The more I look at things here its quite easy to see why Sony would get salty with nvidia but Sony should have known better - nvidia gonna nvidia, which is to say blow smoke screens and say whatever BS they can to make something seem like a non-issue.

Go to settings in MFWBuilder on the far right, Add the PS3_Keys. There should be a folder in the program directory

I did that as part of the setup process for MFW, I will try moving the keys out of the folder or something.

What I did
File > Settings
Select Temp folder location for the build process
Select ps3 keys folder location
Click Save
Selected "4.xx CEX Base Firmware"
Unchecked "Sign isolated modules" and "Sign self/sprx"
Placed the firmware to modify in the OFW folder then browsed to it in MFW builder under "Original Firmware"
Browsed to the location to save the modified firmware to under "Modified Firmware"

 

[Tanzu15]

Essentially the Cell can be considered to have the same horrible performance as P4s with net(nut)burst then, something along the lines of a Willamette lets say. 25.6GB\s bandwidth really isnt a lot by the time you have factored in overhead(s) (such as API used, latency, etc) and that figure is only specifically for the XDR system memory anyway, read\write operations are further crippled to 20\15GB\s (at best) depending if data is coming from or going to the Cell which is why I say CPU bandwidth is an issue and why an XDR OC would likely be rather helpful. Pipeline stalls will be a regular occurrence if shitty code is running on top of all of those other issues as well. Probably why so many games can dip under 20FPS, the worst Ive seen so far is with AC1, near the end of the game frame rate can bomb hard down to like 11-12FPS at critical times making things totally unplayable. Things like that never should have been allowed past QC but given the fairly open and large detailed maps that bandwidth is a good shout for being the cause on both CPU and RSX but I will stick my neck out and say more the CPU. Not entirely the CPUs fault though Ubisoft likely did nothing to optimise the code for the Cell.

As for the RSX, it not supporting anything like scheduling isnt a major issue up to a certain point you can create command lists to circumvent those problems quite nicely the problem arises when you keep piling things on the GPU without any mitigation code to take into account the GPU having more limited capabilities. The more I look at things here its quite easy to see why Sony would get salty with nvidia but Sony should have known better - nvidia gonna nvidia, which is to say blow smoke screens and say whatever BS they can to make something seem like a non-issue.



I did that as part of the setup process for MFW, I will try moving the keys out of the folder or something.

What I did
File > Settings
Select Temp folder location for the build process
Select ps3 keys folder location
Click Save
Selected "4.xx CEX Base Firmware"
Unchecked "Sign isolated modules" and "Sign self/sprx"
Placed the firmware to modify in the OFW folder then browsed to it in MFW builder under "Original Firmware"
Browsed to the location to save the modified firmware to under "Modified Firmware"

Would Overclocking that XDR memory be possible?

 

[Ketxxx]

Would Overclocking that XDR memory be possible?

All overclocking is possible in theory, just have to work out how everything is linked which is the tricky part you don't want to be doing something like overclocking the bus for the storage controller at the same time for instance, that would be really, really bad. You'd corrupt storage devices left and right.

You can't even make an estimated prediction on what kind of performance uplift there would be as I don't think XDR efficiency is easily available information. I would try and put some VERY rough numbers together making some general assumptions but I'm way too tired for that right now. Suffice to say a 15-30% bandwidth improvement variable factors considered wouldn't be out of the realms of possibility depending how high the OC is. I'll try to work some numbers out when I'm not knackered but if we assume 25.6GB\s is the theoretical maximum with a real-world maximum being 21GB\s say then you could say operational efficiency is 82% on average. Taking poor coding in mind though it could be as low as about 60% in some cases which would be about 15.3GB\s.

 

[Tanzu15]

All overclocking is possible in theory, just have to work out how everything is linked which is the tricky part you don't want to be doing something like overclocking the bus for the storage controller at the same time for instance, that would be really, really bad. You'd corrupt storage devices left and right.

You can't even make an estimated prediction on what kind of performance uplift there would be as I don't think XDR efficiency is easily available information. I would try and put some VERY rough numbers together making some general assumptions but I'm way too tired for that right now. Suffice to say a 15-30% bandwidth improvement variable factors considered wouldn't be out of the realms of possibility depending how high the OC is. I'll try to work some numbers out when I'm not knackered but if we assume 25.6GB\s is the theoretical maximum with a real-world maximum being 21GB\s say then you could say operational efficiency is 82% on average. Taking poor coding in mind though it could be as low as about 60% in some cases which would be about 15.3GB\s.

You're the goat bro thanks for this. Sadly don't think anyone is working on getting more Overclocks to work. The PS3 is just untapped with potential to make things faster.

 

[Succ]

I saw that evilnat finally released the OC Variety of 4.91 PEX and I wanted to get into overclocking and I wanted to post my findings. I have been testing the Overclocking firmware for the first time. I have a CECHA00 40nm Frankenstein ps3 with new capacitors with the tantalACEr array for the capacitors. I tried using the base OC of 600/750. Perfectly stable! Tried going up from there using small increments because I don't have a NAND hardware flasher on me at the moment so I was being as cautious as I possibly could.

I almost F'ed up when I jumped to 850/875. I noticed severe artifacting when I played 3D dot game heroes and i immediately quit out of the game and toned down the OC to 800/850. I then played TLOU with those setting and i noticed artifacting after a while on the door in the opening scene.

I downgraded it further to 800/800 and it seemed stable although I noticed something weird with my mounted games (turns out, webman messed up my mounted games during the process so I used Managunz to remount the games and they work perfectly now). I took that as I sign that my OC was too high and I then used 700/800 which was perfectly stable.

I then had an itch too see if I can push my console a little further so I tried using 800/800 again to see if it was stable. I played Crysis and noticed bad artifacts so I then tried 750/900. I read on this thread that too high gpu clocks can cause artifacting while too high VRAM can cause instability. Since I haven't had any instability issues at 800 VRAM, id figure why not try 900 VRAM and see what happens.

750/900 seems to be going good so far but I did noticed some very small artifacts during the opening scene of cyrsis but they went away and were short lived. Right now I'm using TLOU for stability testing and after about 30 mins, it seems to be running good with no crashes or artifacts.

in case you're curious, the console has MX-6 thermal paste, my webman fan speed was set to AUTO at 68C, and my room temperature is 20C spring coming up on summer.

 

[Tanzu15]

I saw that evilnat finally released the OC Variety of 4.91 PEX and I wanted to get into overclocking and I wanted to post my findings. I have been testing the Overclocking firmware for the first time. I have a CECHA00 40nm Frankenstein ps3 with new capacitors with the tantalACEr array for the capacitors. I tried using the base OC of 600/750. Perfectly stable! Tried going up from there using small increments because I don't have a NAND hardware flasher on me at the moment so I was being as cautious as I possibly could.

I almost F'ed up when I jumped to 850/875. I noticed severe artifacting when I played 3D dot game heroes and i immediately quit out of the game and toned down the OC to 800/850. I then played TLOU with those setting and i noticed artifacting after a while on the door in the opening scene.

I downgraded it further to 800/800 and it seemed stable although I noticed something weird with my mounted games (turns out, webman messed up my mounted games during the process so I used Managunz to remount the games and they work perfectly now). I took that as I sign that my OC was too high and I then used 700/800 which was perfectly stable.

I then had an itch too see if I can push my console a little further so I tried using 800/800 again to see if it was stable. I played Crysis and noticed bad artifacts so I then tried 750/900. I read on this thread that too high gpu clocks can cause artifacting while too high VRAM can cause instability. Since I haven't had any instability issues at 800 VRAM, id figure why not try 900 VRAM and see what happens.

750/900 seems to be going good so far but I did noticed some very small artifacts during the opening scene of cyrsis but they went away and were short lived. Right now I'm using TLOU for stability testing and after about 30 mins, it seems to be running good with no crashes or artifacts.

in case you're curious, the console has MX-6 thermal paste, my webman fan speed was set to AUTO at 68C, and my room temperature is 20C spring coming up on summer.

Crysis HD is a better test for overall stability. You're lucky you didn't brick your system. You were supposed to start from 650/800 mem if it's a Frankie, cause frankie process could degrade silicon OC potential due to the heat. OC on Frankies are the only data we don't have much on here. Now data on slims we do have. Plenty. I have tons of data due to me buying and owning like 7 or 8 PS3s. And I know what all the PS3s silicon are capable of based on model and manufacture date.