Author Topic: CPU Performance DD2.2 vs DD2.3 (v2)  (Read 882 times)

Borley

  • Newbie
  • *
  • Posts: 39
  • Karma: +4/-0
    • View Profile
CPU Performance DD2.2 vs DD2.3 (v2)
« on: May 02, 2020, 04:32:31 pm »
I have been unable to find any documented information on the v2 chips beyond the listed features and some vague "5% in some cases" claim on IRC. So I went ahead and got a CP9M31 (v2) to compare. It was a drop in replacement for my Blackbird with the 1.01 firmware. After the system rebooted once with no POST chirp (and a minor heart attack) it proceeded to start up normally. Although the language on the Wiki seems to imply that the new 2.00 firmware is required to run v2 parts?: "PNOR Supports DD2.3 ("v2") CPUs".

Here are some really basic CPU benchmarks with hardinfo:

CPU partCP9M01CP9M31
BlowfishNo data2.04(Lower is better)
CryptoHash854.30945.86(Higher is better)
Fibonacci0.940.94(Lower is better)
N-Queens15.8816.21(Lower is better)
Zlib1.591.54(Higher is better)
FPU FFT1.461.43(Lower is better)
FPU Raytrace2.072.04(Lower is better)

I wouldn't call the test scientific as I did have Gnome system monitor and psensor open in the backgroud for the second run. Interestingly, the part with speculative execution mitigations actually fared worse in N-Queens and Zlib. But it does perform better overall, especially cryptohash. Sorry about the Blowfish stat, my first run didn't grab it and I had already rebuilt my system before I realized it. I will update the table if anybody who has a CP9M01 currently installed wants to run a quick hardinfo benchmark to contribute.

Is this worth adding to the wiki? What would be an appropriate page?

AbstractConcept

  • Newbie
  • *
  • Posts: 14
  • Karma: +0/-0
    • View Profile
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #1 on: May 02, 2020, 07:56:20 pm »
Since the stepping is specific to the chip (Nimbus in this case), I think it would make sense to add your findings to the Steppings secton of the POWER9 page; if we start to get too-much Nimbus-specific information, it can always be split off into a separate page.

As an aside, the CP9M## is not actually a part number, it is (as far as I can tell) just a SKU for Raptor to manage their inventory; according to ClassicHasClass you can see the actual part number in lshw. We are actually missing the parts number for the CP9M31 SKU in the decoder table on the Sforza page, if you could add what yours is that would be excellent.
« Last Edit: May 02, 2020, 08:00:11 pm by AbstractConcept »

ClassicHasClass

  • Full Member
  • ***
  • Posts: 164
  • Karma: +11/-0
  • Talospace Earth Orbit
    • View Profile
    • Floodgap
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #2 on: May 03, 2020, 06:07:58 pm »
I'd strongly recommend you were on at least system package 2.00 for DD2.3, yes. It might be glitchy on earlier releases.

MPC7500

  • Sr. Member
  • ****
  • Posts: 284
  • Karma: +16/-1
    • View Profile
    • Twitter
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #3 on: May 03, 2020, 07:11:47 pm »
Isn't hardinfo available on Fedora?

FlyingBlackbird

  • Jr. Member
  • **
  • Posts: 92
  • Karma: +0/-0
    • View Profile
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #4 on: May 05, 2020, 06:31:33 am »
AFIKR `cat /proc/cpuinfo` also shows the stepping ("revision: 2.3" for the "v2" CPU)

Since the stepping is specific to the chip (Nimbus in this case), I think it would make sense to add your findings to the Steppings secton of the POWER9 page; if we start to get too-much Nimbus-specific information, it can always be split off into a separate page.

As an aside, the CP9M## is not actually a part number, it is (as far as I can tell) just a SKU for Raptor to manage their inventory; according to ClassicHasClass you can see the actual part number in lshw. We are actually missing the parts number for the CP9M31 SKU in the decoder table on the Sforza page, if you could add what yours is that would be excellent.

Borley

  • Newbie
  • *
  • Posts: 39
  • Karma: +4/-0
    • View Profile
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #5 on: May 05, 2020, 07:06:17 am »
I'd strongly recommend you were on at least system package 2.00 for DD2.3, yes. It might be glitchy on earlier releases.

It has been largely running fine since installed, aside from that odd 2x cold boot. I am hesitant to upgrade the firmware as there is [still] no really clear procedure and I don't have the spare equipment to remediate if anything goes wrong.

surf

  • Newbie
  • *
  • Posts: 18
  • Karma: +1/-0
    • View Profile
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #6 on: May 05, 2020, 09:41:07 pm »
I am hesitant to upgrade the firmware... 

I wonder if Raptor would burn some flash chips and mail them?  Then you could literally swap out the firmware, and swap back if needed...

ClassicHasClass

  • Full Member
  • ***
  • Posts: 164
  • Karma: +11/-0
  • Talospace Earth Orbit
    • View Profile
    • Floodgap
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #7 on: May 05, 2020, 11:03:53 pm »
Quote
as there is (still) no really clear procedure

How do you mean? It's mostly upload the new BMC flash, note the MAC addresses, let it reset itself, reset the MAC addresses to their prior values, and then update the PNOR.

tle

  • Full Member
  • ***
  • Posts: 130
  • Karma: +23/-0
    • View Profile
    • Ruby Journal
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #8 on: May 06, 2020, 04:37:47 am »
Isn't hardinfo available on Fedora?

AFIK the hardinfo RPM was dropped from the main repo tree few years ago.

And I did not have much luck with compiling it. I've lodged a ticket at https://github.com/lpereira/hardinfo/issues/539

I got it working :D, the patch for Fedora 32 from me https://github.com/lpereira/hardinfo/pull/540
« Last Edit: May 06, 2020, 08:31:06 pm by tle »
Faithful Linux enthusiast

Borley

  • Newbie
  • *
  • Posts: 39
  • Karma: +4/-0
    • View Profile
Re: CPU Performance DD2.2 vs DD2.3 (v2)
« Reply #9 on: May 07, 2020, 05:50:30 pm »
How do you mean? It's mostly upload the new BMC flash, note the MAC addresses, let it reset itself, reset the MAC addresses to their prior values, and then update the PNOR.

To be fair, it's been a long time since I checked the information. I just recall seeing a lot of WIP discussion at the time and decided to take the conservative approach.