NOTNlCE / Dell-Precision-T5810-OpenCore

OpenCore for the Dell Precision T5810
2 stars 0 forks source link

Low Geekbench 5 scores - CPU Power Management not running optimally? #3

Closed BillDH2k closed 1 year ago

BillDH2k commented 2 years ago

Running stable under Catalina/Big Sur. But for some reason, the Geekbench 5 score is very low. The scores were only 733 (single-core), and 4967 (multi-core), with 2666V3 32GB RAM.

For comparison, the same hardware/OS install, running from my old OC setup (Catalina), the scores were much higher - 875, 7064, respectively. My speculation is that the CPU Power Management might not be running optimally. My old OC setup was from another GitHub contributor (link here).

By comparing the difference between the setup, an expert eye, like yours, might be able to fix this.

Thanks!

NOTNlCE commented 2 years ago

Power Management has always been tough on X99/C612. I suspect your CPU is not hitting full turbo frequency or proper stepping. There are only so many things we can do here, and I suspect the differences in your CPU score have to do with the frequency vectors being used and whether or not Speed Step was enabled in BIOS on your previous configuration.

In the previous EFI, your XCPM value is defined by SSDT - notably, SSDT-CP00-XCPM.aml. Without that definition, the system falls back to native frequency vectors in the iMacPro1,1 SMBIOS, which have some odd behaviors on our platform.

One thing you can test is re-injecting that SSDT from your old EFI. It should not cause a boot failure, as it is just XCPM data. I'd be very interested to see how it behaves on both your systems and if it requires any tweaks or breaks sleep. I'd also be very interested to see your frequency range with and without the SSDT. This can be monitored with Intel Power Gadget, but with laregely multi-core CPUs, the data gets a little jumbled because it averages all cores. In theory, these systems should be able to idle at 1.3~GHz (Minimum C-State on v3/v4 Xeons) and boost to the maximum turbo frequency of each CPU, but because of platform differences and non-native XCPM, the CPU does one of two things, depending on whether or not Speed Step is enabled. I suspect this toggle in BIOS is more likely the cause of your performance drop.

With Speed Step enabled, CPU idles properly, but doesn't boost properly. While I haven't seen this on my T5810 (mainly because I don't run it every day) I suspect a similar result as my main X99 system running on an ASUS motherboard. Even under load, the CPU frequency doesn't boost up which causes video playback stutter and other non-desirable behavior.

Which leads us to scenario #2, Speed Step disabled: With native frequency vectors (no external XCPM data) the CPU operates slightly above its base clock and stays relatively stable, regardless of load. No idle down frequency, and no boost to maximum turbo frequency.

Now, keep in mind, we are comparing different systems when I am talking about this CPU behavior, but I suspect similar results as the platforms are the same. As another test, I will take this XCPM SSDT and try it on my X99 tower to see how performance is impacted both with Speed Step enabled and disabled.

NOTNlCE commented 2 years ago

Looking at this further, it looks like I am incorrect on the SSDT. It appears to just be an XCPM enabler, so you're likely using the same frequency vectors. I suspect Speed Step is the issue, as I outlined above.

BillDH2k commented 2 years ago

Thank you for your detailed reply!

With your initial suggestion, I replaced ssdt-plug.aml with previous used SSDT-CP00-XCPM.aml. The GB result, as you suspected, did not change.

Now comes the interesting part: I managed to boot up the same system (A33 BIOS) with the old EFI (had tons of trouble before, never able to pass A09)! Now, I am able to run both setups on exactly the same hardware without any change in BIOS settings. The result is the same story of the difference btw the BG5 scores.

The previous EFI had more ACPI/kermel patches applied. Notably, a few XCPM related (by Pike R. Alpha), but I thought they were no longer necessary with newer OC. Anyway, this is bit beyond my current knowledge without additional readings.

Let me know, if you have any suggestions for me to try. I believe this is a solvable issue.

Thanks!

BillDH2k commented 2 years ago

When I get a chance later, I will try to add those xcpm related patches from old setup back to see if that will make a difference.

NOTNlCE commented 2 years ago

From what I understand, the Pike and nmano patches are not required anymore, but can be used instead of the standard OC setup. When troubleshooting similar issues on my ASUS X99 system, I did swap the patches in place, but they can change with each OS update and I found that there was no notable change in performance - but please, I'd love to be wrong here. It has been some time since I last tried this.

My T5810 is sitting by me now - I will get a fresh Geekbench run with Speed Step on and off to see if there is a noticeable difference.

NOTNlCE commented 2 years ago

Hm, this is puzzling.

With SpeedStep: https://browser.geekbench.com/v5/cpu/14682139 Without SpeedStep: https://browser.geekbench.com/v5/cpu/14682252

This did not have the impact I was expecting. I'll have to search around a bit and see what I can find.

EDIT: This is more of the result I was expecting. Here is my main X99 system running a 14-Core Xeon E5-2697v3 with Speed Step Disabled vs. Enabled.

Without SpeedStep: https://browser.geekbench.com/v5/cpu/14682698 With SpeedStep: https://browser.geekbench.com/v5/cpu/14682924

It is possible it impacts systems with more CPU cores worse than those with fewer. The first test on my T5810 uses an E5-1640v4 which is only 4C/8T.

BillDH2k commented 2 years ago

I followed your test on my system, but I got opposite results - lower scores if Speed Step is disabled.

Without SpeedStep: https://browser.geekbench.com/v5/cpu/14687118 With SpeedStep: https://browser.geekbench.com/v5/cpu/14687346

With SpeedStep disabled, the PM continue to function (because of C-State is still there?) except it max-out at 2.9 GHz, instead of 3.5 GHz. See screen capture of the Intel Power Gadget.

Without SpeedStep: No-SpeedStep

With SpeedStep: With-SpeedStep

BillDH2k commented 2 years ago

Now, with the older OC (060), Intel Gadget showed the Core Freq. at 25.5 GHz! Other then this anomaly, PM appeared to work properly, including Sleep/Wake.

The much higher GB score (inline with my other unit HP Z440, X99): https://browser.geekbench.com/v5/cpu/14687548

Intel Gadget screen: Old-OC

NOTNlCE commented 2 years ago

Sorry for the delay. I dug up an E5-2630 v3 8C/16T CPU that I can install in my T5810 this week for a higher core count comparison. It is possible that the ACPI renames present in the older OpenCore are necessary for the CPU boost on higher core count systems. I have many present on my main X99 tower, as that EFI was based off the original KGP EFI from some years back. I will run some tests with the newer CPU and check results.

BillDH2k commented 2 years ago

After a long break, I came back to this issue. I did the following test by copying all PM related kernel patches, as well as the different CPUID/Mask, from the older EFI (OC060) to your EFI. Then boot up Big Sur, and run Geekbench 5. The result was a much better score, 879/7115, compared to the much lower 733/4967. So as you speculated before, the older patches worked differently and able to push the CPUs to higher clock rates.

https://browser.geekbench.com/v5/cpu/17620827

So at least for V3 Xeons, revert to the older PM patches is a good choice. Not sure about the V4 Xeon. May be you could do comparison test with your CPU.

Also, I will do the same test on my Z440, because I suspect it would also improve the PM performance.

Regards, BDH

NOTNlCE commented 2 years ago

These numbers are much more in line with what I expect to see. Perhaps this is just an oddity with the T5810 UEFI as opposed to other X99/C612 systems. I will dig out the 8C/16T and see if it makes a difference vs. the 4C/8T v4.

BillDH2k commented 2 years ago

I agree that T5810 is an oddity. Below are test results from a Z640 system (one CPU, equiv. of Z440) with two different CPUs (1630V3, 2666V3). The scores with default PM (non-patched) is much higher than T5810, but with patched PM, the cores gained additional ~18% and ~14%, for 1630V3 and 2666V3 respectively. I run the test several times in a row, and compare the averaged results.

System: HP Z640, 1630V3, 32GB, BigSur -

Patched PM: Run SingleCore Multi-Core https://browser.geekbench.com/v5/cpu/17634959 Run-1 939 4027 https://browser.geekbench.com/v5/cpu/17635031 Run-2 943 4026 https://browser.geekbench.com/v5/cpu/17635091 Run-3 840 3544 https://browser.geekbench.com/v5/cpu/17635167 Run-4 947 4024 https://browser.geekbench.com/v5/cpu/17635231 Run-5 938 4038 Avg 921 3932

Non-patched PM:
https://browser.geekbench.com/v5/cpu/17631562 Run-1  817 3398 https://browser.geekbench.com/v5/cpu/17631656 Run-2 761 3467 https://browser.geekbench.com/v5/cpu/17631740 Run-3 766 3065 Avg 781 3310

Improvement of Patched-PM vs Non-Patched PM: 17.9% 18.8%

System: HP Z640, 2666V3, 32GB, BigSur -

Patched PM: Run SingleCore Multi-Core https://browser.geekbench.com/v5/cpu/17635455 Run-1 868 7858 https://browser.geekbench.com/v5/cpu/17635551 Run-2 837 7845 https://browser.geekbench.com/v5/cpu/17635757 Run-3 869 7818 https://browser.geekbench.com/v5/cpu/17635833 Run-4 811 7091 https://browser.geekbench.com/v5/cpu/17635894 Run-5 867 7844 Avg 850 7691

Non-patched PM:
https://browser.geekbench.com/v5/cpu/17636018 Run-1 705 6939 https://browser.geekbench.com/v5/cpu/17636103 Run-2 703 6245 https://browser.geekbench.com/v5/cpu/17636170 Run-3 742 7122 https://browser.geekbench.com/v5/cpu/17636269 Run-4 762 6639 https://browser.geekbench.com/v5/cpu/17636342 Run-5 743 7087 Avg 731 6806

Improvement of Pathed PM vs Non-Patched PM: 16.3% 13.0%

BillDH2k commented 2 years ago

The following are two useful links I found for X99/X299 CPU power management topic. The 1st one are for Catalina OS, the 2nd one for newer OS. Through it was said the newer patches were supposedly implemented in OpenCore, but apparently not optimized.

  1. KernelAndKextPatches 10.13x,10.14.x,10.15.x X99/X299 (Link).

  2. Open CORE Kernel & Kext patch for X99/X299 motherboard (link).

BillDH2k commented 2 years ago

One last update - after numerous trials, I've concluded that all these special "patches" (if they were working - ok in Big Sur, but not in Monterey) can be accomplished by simply enabling the kernel quirk "AppleXcpmForceBoost = True". Geekbench 5 would achieve the same high scores. It works under Monterey! This quirk, based on googled information, is trying to force the CPU in Turbo states, thus running at higher clocks. CPU Power Management appeared to have the same behavior, based on Intel Power Gadget, as well as AppleIntelInfo.kext output.

May be this is what it meant that "these patches were implemented in OpenCore". It really helps the T5810 performance. Also ~10-15% improvements on other X99 systems.

NOTNlCE commented 2 years ago

Excellent - I suspect you are correct! I do not have this quirk enabled on my X99 system or the T5810. I will update OpenCore on my main tower and enable the quirk to see if there is a change.

How does the quirk affect idle power consumption, or minimum core clocks? The warning label on the OC docs states, "Forces maximum multiplier, only recommended to enable on scientific or media calculation machines that are constantly under load. Main Xeons benefit from this." I suspect this is why the Xeons are suffering - they are not able to hit their peak without this. Though, for a machine that is relatively idle all day, perhaps this is a compromise or choice that must be made.

BillDH2k commented 2 years ago

Power consumption is definitely higher. See the IPG graph during GB5 runs with and without "AppleXcpmForceBoost" quirk. The avg. frequency was hitting maximum with this quirk enabled. Also during the idle states, the CPU is running cool (the right graph). This was a test run on a HP Z440, 1630V3, Big Sur.

GB5 - Compare 2

Also, The CPU was able to hit lower clock frequency, but less frequently:

AppleIntelIno - XcpmBoost

BillDH2k commented 2 years ago

So, for heavy work, like editing a video, one should turn on this quirk. So far, I am happy with this outcome.

The next challenge is get Monterey working! It encounters a kernel panic, appeared to always at the same spot. People with T5610 appeared to have exactly the same issue.

BillDH2k commented 1 year ago

Just to update here, that I discovered a little efi tool, ResetTSCAdjust.efi, which I used to reset CPU TSC before launching macOS from OpenCore. This solved the kernel panic caused by "non-monotonic time" under Monterey/Ventura booting. See my post here.

NOTNlCE commented 1 year ago

Thanks for all your research and work with this, @BillDH2k - incorporating quirk and ResetTSCAdjust.efi into this week's release.