Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

Edit2 " is not correct :)

2696 V4 22 core/44 threads

TDP 150 w (145 is for 2699 V4)

max turbo is 3700Mhz for two cores  (for all core/threads is 2800 Mhz)

 

this patch cuts the benefit od EIST enabled which in OSX produce a lower frequency for Higher load states and frequency with EIST bounches  from 2.2Ghz to 2.4Ghz or so during load test

 

with this patch during load (only during load test ) frequency is locked to 2600 GHz

then when load is finished system have lower frequency as steps as usually

 

---

 

EDIT: Also your frequency is going well into 3GHz+ while not under load, what's up with that?

 

EDIT2: Nevermind. I see, I was looking at the v3 of that chip, apparently the v4 is 2.2Ghz and 3.2 GHz turbo, with 145W TDP. So either way it's still not correct.

 

EDIT3: It's impossible to have any turbo under 100% load on every thread/core. So what is this patch doing?


I see now you have studied :) (thank you for dude)

 

Pike says this not having as you a similar cpu to test

 

https://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-2699-v4-55M-Cache-2_20-GHz

 

so you can study better (mine is a OEM version of 2699 V4 with some different specs (150 w and x37 for max turbo instead of 145 and x36)

 

forgive me but it is very ridiculous to follow how you edit your posts to find some prove I am saying {censored}

If you read and understand well that thread first EIST was advised to be disabled..then after all my testing on my system Pike advice to enabled it because from appleintelinfo output data it was supported well

And the I have said of bad performance in OSX with EIST enabled

 

thats all

 

 

 

I don't understand this at all. Instead of discarding all the keystrokes by reading them all before loading drivers, after loading the drivers, locate the aggregator protocol and inspect it's key buffer..........


 

I am reading intel documents. Yes, I mistook that you had the v3, not v4, but either way, the numbers you are saying do not match up to what intel says. First the CPU is 2.2GHz so that is all the higher you should be hitting on a 100% multithreaded test, second 2.6GHz is not even one of the turbo multipliers the CPU can reach! They are 37/37/35/34/33/32/31/30/29/28.... And nominal is 22. How are you even reaching 26?

 

EDIT: DUDE, there is a thread on github with you and Pike participating, where he clearly tells you not to use that patch because it defeats the purpose of XCPM, as I was suspecting that it was.

Link to comment
Share on other sites

Edit2 " is not correct :)

2696 V4 22 core/44 threads

TDP 150 w (145 is for 2699 V4)

max turbo is 3700Mhz for two cores  (for all core/threads is 2800 Mhz)

 

this patch cuts the benefit od EIST enabled which in OSX produce a lower frequency for Higher load states and frequency with EIST bounches  from 2.2Ghz to 2.4Ghz or so during load test

 

with this patch during load (only during load test ) frequency is locked to 2600 GHz

then when load is finished system have lower frequency as steps as usually

 

Actually that is EIST working exactly as it should. It should be bouncing around the nominal frequency when around 100% multithreaded load, there's not much left over energy to enter turbo states in this situation. And I made a typo, I meant 3.7GHz, evidenced by my following comment where I wrote out the turbos.

Link to comment
Share on other sites

I don't understand this at all. Instead of discarding all the keystrokes by reading them all before loading drivers, after loading the drivers, locate the aggregator protocol and inspect it's key buffer..........

 

I am reading intel documents. Yes, I mistook that you had the v3, not v4, but either way, the numbers you are saying do not match up to what intel says. First the CPU is 2.2GHz so that is all the higher you should be hitting on a 100% multithreaded test, second 2.6GHz is not even one of the turbo multipliers the CPU can reach! They are 37/37/35/34/33/32/31/30/29/28.... And nominal is 22. How are you even reaching 26?

 

EDIT: DUDE, there is a thread on github with you and Pike participating, where he clearly tells you not to use that patch because it defeats the purpose of XCPM, as I was suspecting that it was.

 

Do we need to handle apple boot key combo, or just check if there is keystrokes to invoke the GUI?

I meant if boot.efi's job including read from the protocol?

Link to comment
Share on other sites

Do we need to handle apple boot key combo, or just check if there is keystrokes to invoke the GUI?

I meant if boot.efi's job including read from the protocol?

 

Well should the GUI start if you know the key combination is meant for boot.efi? Probably not. It should probably just boot, but that's only if boot.efi is the selected bootloader, otherwise it should enter the GUI because those key combinations don't mean anything for other OSes and you can get to all that stuff from the GUI in that case.

I see now you have studied :) (thank you for dude)

 

Pike says this not having as you a similar cpu to test

 

https://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-2699-v4-55M-Cache-2_20-GHz

 

so you can study better (mine is a OEM version of 2699 V4 with some different specs (150 w and x37 for max turbo instead of 145 and x36)

 

forgive me but it is very ridiculous to follow how you edit your posts to find some prove I am saying {censored}

If you read and understand well that thread first EIST was advised to be disabled..then after all my testing on my system Pike advice to enabled it because from appleintelinfo output data it was supported well

And the I have said of bad performance in OSX with EIST enabled

 

thats all

 

I am looking at an Intel document for Xeon E5-2696 v4. I edited my posts before you had responded. I am just still trying to figure out why you need this patch when you could change the p state information. Maybe I just don't understand sacrificing a ton of power management for a small increase in output.

Link to comment
Share on other sites

first three benchmark are with patch enabled (or without EIST enabled in bios)

 

last two benchmark with EIST enabled in bios and without patch in clover

 

 


edit 

if you can share Intel 2696 V4 document I will be grateful (no need for 2699 V4 but exactly mine)

 

 

I am looking at an Intel document for Xeon E5-2696 v4. I edited my posts before you had responded. I am just still trying to figure out why you need this patch when you could change the p state information. Maybe I just don't understand sacrificing a ton of power management for a small increase in output.

post-468967-0-65001000-1518450194_thumb.png

Link to comment
Share on other sites

 

@slice @PMHeart
 
I suggest to optimize Chinese descriptions in Clover Install GUI such as Driver64UEFI.
If descriptions have some mistake please fix it.
Thanks.
 
AptioInputFix
Vit9696编写的针对FileVault2启动界面的键盘和鼠标输入设备的支持
 
 
AptioMemoryFix
Vit9696自OsxAptioFix2驱动优化而来的新驱动,支持更多新特性,例如:
 

自动为boot.efi寻找最适合的内存地址,避免启动错误

当slide值不能被使用的时候提供对KASLR的支持
新增系统在低内存地址下的安全模式的支持
确保系统不会出现slide溢出的问题
尝试修复更多的内存分布问题
支持硬件NVRAM
优化一些休眠的问题(暂时不稳定)
(请勿与其余内存修复驱动同时使用)
 
 
CsmVideoDxe-64
提供对CSM模块的支持,某些主板若要安装非UEFI系统或者非安全启动的系统,例如Windows7,Linux等设备,需要开启CSM模块,此时需要加入该驱动以修复CloverGUI的显示问题
Clover推荐关闭CSM模块启用原生GOP显示模块
 
 
EmuVariableUefi-64
macOS使用NVRAM存储一些系统变量,大部分的UEFI主板在配合合适的Aptio驱动后支持原生硬件NVRAM,但是少部分主板不支持NVRAM或者NVRAM的支持有问题,此时建议加入该驱动,该驱动通过开机时加载位于EFI分区内的nvram.plist内容到nvram中,以模拟NVRAM支持
需要注意的是,是用此驱动,需要勾选“安装RC scripts到目标磁区”选项才有效
 
 
Fat-64
可选择的64位FAT文件系统的支持
 
 
OsxAptioFixDrv-64
Dmazar编写的针对UEFI固件的内存问题修复的驱动,对休眠支持不完善
(请勿与其余内存修复驱动同时使用)
 
 
OsxAptioFix2Drv-64
Dmazar编写的针对UEFI固件的内存问题修复的驱动,在1代基础之上完善了休眠等高级功能的支持,部分机型需要手动设置slide值
(请勿与其余内存修复驱动同时使用)
 
 
OsxAptioFix3Drv-64
Vit9696等作者在OsxAptioFix2Drv-64的基础之上进行了优化,修复了大多数新设备的NVRAM支持,该驱动在部分机型依然需要手动设置slide值
(请勿与其余内存修复驱动同时使用)
 
 
OsxFatBinaryDrv-64
可选择的64位FAT文件系统的支持
 
 
OsxLowMemFixDrv-64
针对UEFI固件内存问题修复的驱动简化版
(请勿与其余内存修复驱动同时使用)
 
 
PartitionDxe-64
支持非常态的分区配置,如苹果混合分区或Apple分区图。
 
 
UsbkbDxe-64
FileVault2启动界面的键盘输入设备的支持
 
 
UsbMouseDxe-64
FileVault2启动界面的鼠标输入设备的支持

 

 

 

@slice @PMHeart
 
I suggest to optimize Chinese descriptions in Clover Install GUI such as Driver64UEFI.
If descriptions have some mistake please fix it.
Thanks.
 
AptioInputFix
Vit9696编写的针对FileVault2启动界面的键盘和鼠标输入设备的支持
 
 
AptioMemoryFix
Vit9696自OsxAptioFix2驱动优化而来的新驱动,支持更多新特性,例如:
 

自动为boot.efi寻找最适合的内存地址,避免启动错误

当slide值不能被使用的时候提供对KASLR的支持
新增系统在低内存地址下的安全模式的支持
确保系统不会出现slide溢出的问题
尝试修复更多的内存分布问题
支持硬件NVRAM
优化一些休眠的问题(暂时不稳定)
(请勿与其余内存修复驱动同时使用)
 
 
CsmVideoDxe-64
提供对CSM模块的支持,某些主板若要安装非UEFI系统或者非安全启动的系统,例如Windows7,Linux等设备,需要开启CSM模块,此时需要加入该驱动以修复CloverGUI的显示问题
Clover推荐关闭CSM模块启用原生GOP显示模块
 
 
EmuVariableUefi-64
macOS使用NVRAM存储一些系统变量,大部分的UEFI主板在配合合适的Aptio驱动后支持原生硬件NVRAM,但是少部分主板不支持NVRAM或者NVRAM的支持有问题,此时建议加入该驱动,该驱动通过开机时加载位于EFI分区内的nvram.plist内容到nvram中,以模拟NVRAM支持
需要注意的是,是用此驱动,需要勾选“安装RC scripts到目标磁区”选项才有效
 
 
Fat-64
可选择的64位FAT文件系统的支持
 
 
OsxAptioFixDrv-64
Dmazar编写的针对UEFI固件的内存问题修复的驱动,对休眠支持不完善
(请勿与其余内存修复驱动同时使用)
 
 
OsxAptioFix2Drv-64
Dmazar编写的针对UEFI固件的内存问题修复的驱动,在1代基础之上完善了休眠等高级功能的支持,部分机型需要手动设置slide值
(请勿与其余内存修复驱动同时使用)
 
 
OsxAptioFix3Drv-64
Vit9696等作者在OsxAptioFix2Drv-64的基础之上进行了优化,修复了大多数新设备的NVRAM支持,该驱动在部分机型依然需要手动设置slide值
(请勿与其余内存修复驱动同时使用)
 
 
OsxFatBinaryDrv-64
可选择的64位FAT文件系统的支持
 
 
OsxLowMemFixDrv-64
针对UEFI固件内存问题修复的驱动简化版
(请勿与其余内存修复驱动同时使用)
 
 
PartitionDxe-64
支持非常态的分区配置,如苹果混合分区或Apple分区图。
 
 
UsbkbDxe-64
FileVault2启动界面的键盘输入设备的支持
 
 
UsbMouseDxe-64
FileVault2启动界面的鼠标输入设备的支持

 

Hi,

請問如果之前安裝了OsxAptioFix2Drv-64 我可以直接update lover時更換為第三版OsxAptioFix3Drv-64?有何好處?

Link to comment
Share on other sites

first three benchmark are with patch enabled (or without EIST enabled in bios)

 

last two benchmark with EIST enabled in bios and without patch in clover

 

Please give a geekbench result.

 

EDIT: I don't see how you could be getting any states when this is the status of the CPUs configuration, EIST is clearly disabled:

EDIT2: I see now, it's just disabling EIST and HWP, so basically just using speedstep always to the complete maximum..... Which means its not using XCPM.

EDIT3: I never explain enough, I don't think and then it's confusing or something. Basically, this patch appears to always set the target performance state to the maximum value which means that nothing is really working because it's not changing that value to get better performance/power ratio, it's just going all out performance. So even though EIST is enabled, it's really not, if that value is never changed then it will always choose the highest state available, not the most appropriate.

MSR_IA32_PERF_CONTROL............(0x199) : 0xFF00
------------------------------------------
 - Target performance State Value....... : 0xFF00 (25500 MHz)
 - Intel Dynamic Acceleration........... : 0 (IDA engaged)

...

MSR_MISC_PWR_MGMT................(0x1AA) : 0x402000
------------------------------------------
- EIST Hardware Coordination........... : 0 (hardware coordination enabled)
- Energy/Performance Bias support...... : 1
- Energy/Performance Bias.............. : 0 (disabled/MSR not visible to software)
- Thermal Interrupt Coordination Enable : 1 (thermal interrupt routed to all cores)
- SpeedShift Technology Enable......... : 0 (disabled)
- SpeedShift Interrupt Coordination.... : 0 (disabled)
- SpeedShift Energy Efficient Perf..... : 0 (disabled)
- SpeedShift Technology Setup for HWP.. : No (not setup for HWP)

Here are your turbos:

MSR_TURBO_RATIO_LIMIT............(0x1AD) : 0x1E1F202122232525
------------------------------------------
- Maximum Ratio Limit for C01.......... : 25 (3700 MHz) 
- Maximum Ratio Limit for C02.......... : 25 (3700 MHz) 
- Maximum Ratio Limit for C03.......... : 23 (3500 MHz) 
- Maximum Ratio Limit for C04.......... : 22 (3400 MHz) 
- Maximum Ratio Limit for C05.......... : 21 (3300 MHz) 
- Maximum Ratio Limit for C06.......... : 20 (3200 MHz) 
- Maximum Ratio Limit for C07.......... : 1F (3100 MHz) 
- Maximum Ratio Limit for C08.......... : 1E (3000 MHz)

MSR_TURBO_RATIO_LIMIT1...........(0x1AE) : 0x1C1C1C1C1C1C1C1D
------------------------------------------
- Maximum Ratio Limit for C09.......... : 1D (2900 MHz) 
- Maximum Ratio Limit for C10.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C11.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C12.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C13.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C14.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C15.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C16.......... : 1C (2800 MHz)

MSR_TURBO_RATIO_LIMIT2...........(0x1AF) : 0x1C1C1C1C1C1C1C1C
------------------------------------------
- Maximum Ratio Limit for C17.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C18.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C19.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C20.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C21.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C22.......... : 1C (2800 MHz) 
Link to comment
Share on other sites

Will it have any influence on performance, if I change the auto-clover-calculated c3-latency value from 0x00FA to 0X03E9?  Or is that outdated anyway?

 

Ugh, I would just get those from your original tables. Most of the generated CPU stuff is outdated, my advice is never use any of the generated stuff and just patch your tables.

  • Like 1
Link to comment
Share on other sites

Attached a Geekbench test

up without patch

down with patch

 

I don't want open another page about your XCPM assertion..but I can only say with or without patch I have always same appleintelcpuinfo output , temperatures, steps..only performances is lower

 

PS.

Pikeralpha opened a case with Geekbench software because How can also see from this partial IPG graphics during test, Geekbench do not push my xeon at its power and frequency limits

 

 

 
Please give a geekbench result.
 
EDIT: I don't see how you could be getting any states when this is the status of the CPUs configuration, EIST is clearly disabled:

EDIT2: I see now, it's just disabling EIST and HWP, so basically just using speedstep always to the complete maximum..... Which means its not using XCPM.

MSR_IA32_PERF_CONTROL............(0x199) : 0xFF00
------------------------------------------
 - Target performance State Value....... : 0xFF00 (25500 MHz)
 - Intel Dynamic Acceleration........... : 0 (IDA engaged)

...

MSR_MISC_PWR_MGMT................(0x1AA) : 0x402000
------------------------------------------
- EIST Hardware Coordination........... : 0 (hardware coordination enabled)
- Energy/Performance Bias support...... : 1
- Energy/Performance Bias.............. : 0 (disabled/MSR not visible to software)
- Thermal Interrupt Coordination Enable : 1 (thermal interrupt routed to all cores)
- SpeedShift Technology Enable......... : 0 (disabled)
- SpeedShift Interrupt Coordination.... : 0 (disabled)
- SpeedShift Energy Efficient Perf..... : 0 (disabled)
- SpeedShift Technology Setup for HWP.. : No (not setup for HWP)

Here are your turbos:

MSR_TURBO_RATIO_LIMIT............(0x1AD) : 0x1E1F202122232525
------------------------------------------
- Maximum Ratio Limit for C01.......... : 25 (3700 MHz) 
- Maximum Ratio Limit for C02.......... : 25 (3700 MHz) 
- Maximum Ratio Limit for C03.......... : 23 (3500 MHz) 
- Maximum Ratio Limit for C04.......... : 22 (3400 MHz) 
- Maximum Ratio Limit for C05.......... : 21 (3300 MHz) 
- Maximum Ratio Limit for C06.......... : 20 (3200 MHz) 
- Maximum Ratio Limit for C07.......... : 1F (3100 MHz) 
- Maximum Ratio Limit for C08.......... : 1E (3000 MHz)

MSR_TURBO_RATIO_LIMIT1...........(0x1AE) : 0x1C1C1C1C1C1C1C1D
------------------------------------------
- Maximum Ratio Limit for C09.......... : 1D (2900 MHz) 
- Maximum Ratio Limit for C10.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C11.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C12.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C13.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C14.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C15.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C16.......... : 1C (2800 MHz)

MSR_TURBO_RATIO_LIMIT2...........(0x1AF) : 0x1C1C1C1C1C1C1C1C
------------------------------------------
- Maximum Ratio Limit for C17.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C18.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C19.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C20.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C21.......... : 1C (2800 MHz) 
- Maximum Ratio Limit for C22.......... : 1C (2800 MHz) 

 


ohhhh

with edit2 you now understand the meaning of that patch!:)


edit

added sysctl machdep.xcpm output

Last login: Mon Feb 12 18:32:48 on ttys000
fabios-iMac-Pro:~ fabio$ sysctl machdep.xcpm output
machdep.xcpm.mode: 1
machdep.xcpm.hard_plimit_max_100mhz_ratio: 37
machdep.xcpm.hard_plimit_min_100mhz_ratio: 8
machdep.xcpm.soft_plimit_max_100mhz_ratio: 37
machdep.xcpm.soft_plimit_min_100mhz_ratio: 8
machdep.xcpm.tuib_plimit_max_100mhz_ratio: 37
machdep.xcpm.tuib_plimit_min_100mhz_ratio: 8
machdep.xcpm.tuib_enabled: 0
machdep.xcpm.power_source: 0
machdep.xcpm.bootplim: 0
machdep.xcpm.bootpst: 37
machdep.xcpm.tuib_ns: 0
machdep.xcpm.vectors_loaded_count: 1
machdep.xcpm.ratio_change_ratelimit_ns: 500000
machdep.xcpm.ratio_changes_total: 368499
machdep.xcpm.maxbusdelay: 0
machdep.xcpm.maxintdelay: 0
machdep.xcpm.mbd_mode: 1
machdep.xcpm.mbd_applications: 0
machdep.xcpm.mbd_relaxations: 0
machdep.xcpm.forced_idle_ratio: 100
machdep.xcpm.forced_idle_period: 30000000
machdep.xcpm.deep_idle_log: 0
machdep.xcpm.qos_txfr: 1
machdep.xcpm.deep_idle_count: 0
machdep.xcpm.deep_idle_last_stats: n/a
machdep.xcpm.deep_idle_total_stats: n/a
machdep.xcpm.cpu_thermal_level: 0
machdep.xcpm.gpu_thermal_level: 0
machdep.xcpm.io_thermal_level: 0
machdep.xcpm.io_control_engages: 0
machdep.xcpm.io_control_disengages: 1
machdep.xcpm.io_filtered_reads: 0
machdep.xcpm.io_cst_control_enabled: 0
machdep.xcpm.ring_boost_enabled: 0
machdep.xcpm.io_epp_boost_enabled: 0
machdep.xcpm.epp_override: 0
fabios-iMac-Pro:~ fabio$

post-468967-0-04256200-1518456078_thumb.png

Link to comment
Share on other sites

Attached a Geekbench test

up without patch

down with patch

 

I don't want open another page about your XCPM assertion..but I can only say with or without patch I have always same appleintelcpuinfo output , temperatures, steps..only performances is lower

 

The performance is lower because you are trading off power management for unbridled speed. Geekbench runs actual algorithms so the utilization changes as it is used, which is a good thing because it gives a more real time usage result. The scores are marginally different, the utilization is pretty much similar, I'm sure the statistical variance would be small but that power consumption is absolutely more, a lot more. The performance is around 9% gain but how much more energy is that taking? In the first one, you don't hit 120W at all, in the second you hit it seven times, and a very extended eighth time. Just those spots each look around about ~20W more, most of the spots look about ~20W more. So since it was hitting 100W but now hits 120W in the same place, that is a 20% increase in power usage. You are trading a ~20% increase in power consumption for a ~9% increase in output.

 

EDIT: Also 4000 is geekbench's your CPU is great score.

 

ohhhh

with edit2 you now understand the meaning of that patch! :)

 

Does not mean I think it is a good patch. Also that was what I was asking you to explain to me but you weren't.

 

edit

added sysctl machdep.xcpm output

Last login: Mon Feb 12 18:32:48 on ttys000
fabios-iMac-Pro:~ fabio$ sysctl machdep.xcpm output
machdep.xcpm.mode: 1
machdep.xcpm.hard_plimit_max_100mhz_ratio: 37
machdep.xcpm.hard_plimit_min_100mhz_ratio: 8
machdep.xcpm.soft_plimit_max_100mhz_ratio: 37
machdep.xcpm.soft_plimit_min_100mhz_ratio: 8
machdep.xcpm.tuib_plimit_max_100mhz_ratio: 37
machdep.xcpm.tuib_plimit_min_100mhz_ratio: 8
machdep.xcpm.tuib_enabled: 0
machdep.xcpm.power_source: 0
machdep.xcpm.bootplim: 0
machdep.xcpm.bootpst: 37
machdep.xcpm.tuib_ns: 0
machdep.xcpm.vectors_loaded_count: 1
machdep.xcpm.ratio_change_ratelimit_ns: 500000
machdep.xcpm.ratio_changes_total: 368499
machdep.xcpm.maxbusdelay: 0
machdep.xcpm.maxintdelay: 0
machdep.xcpm.mbd_mode: 1
machdep.xcpm.mbd_applications: 0
machdep.xcpm.mbd_relaxations: 0
machdep.xcpm.forced_idle_ratio: 100
machdep.xcpm.forced_idle_period: 30000000
machdep.xcpm.deep_idle_log: 0
machdep.xcpm.qos_txfr: 1
machdep.xcpm.deep_idle_count: 0
machdep.xcpm.deep_idle_last_stats: n/a
machdep.xcpm.deep_idle_total_stats: n/a
machdep.xcpm.cpu_thermal_level: 0
machdep.xcpm.gpu_thermal_level: 0
machdep.xcpm.io_thermal_level: 0
machdep.xcpm.io_control_engages: 0
machdep.xcpm.io_control_disengages: 1
machdep.xcpm.io_filtered_reads: 0
machdep.xcpm.io_cst_control_enabled: 0
machdep.xcpm.ring_boost_enabled: 0
machdep.xcpm.io_epp_boost_enabled: 0
machdep.xcpm.epp_override: 0
fabios-iMac-Pro:~ fabio$

 

This is meaningless if you patch the place where it writes the target performance state to always have the highest value.

Link to comment
Share on other sites

The performance is lower because you are trading off power management for unbridled speed. Geekbench runs actual algorithms so the utilization changes as it is used, which is a good thing because it gives a more real time usage result. The scores are marginally different, the utilization is pretty much similar, I'm sure the statistical variance would be small but that power consumption is absolutely more, a lot more. The performance is around 9% gain but how much more energy is that taking? In the first one, you don't hit 120W at all, in the second you hit it seven times, and a very extended eighth time. Just those spots each look around about ~20W more, most of the spots look about ~20W more. So since it was hitting 100W but now hits 120W in the same place, that is a 20% increase in power usage. You are trading a ~20% increase in power consumption for a ~9% increase in output.

 

EDIT: Also 4000 is geekbench's your CPU is great score.

 

 

Does not mean I think it is a good patch. Also that was what I was asking you to explain to me but you weren't.

 

 

This is meaningless if you patch the place where it writes the target performance state to always have the highest value.

 

Uhmm

Maybe is my today english

 

ok

I use some 3d software for my job

they use intensively cpu when I do some rendering

with patch 20 % faster and cpu locked @2600 Mhz

without patch no

In windows instead no differences

 

watt consuming is another things and I would not like to argument because n my rig I have had also two TitanZ Graphic card (maybe you know how much power they need in the past)

 

Now

This patch is useful for me and for people who have (for various reasons EIST enabled in bios)

And the reason is always the same OSX or some tool I use to boot inside (like bootloader or other) with EIST enable produce for unsupported CPU worst performance

 

Now if it is possible to use this "boost" only when I need (during rendering IE) I will be happy

but for now it wasn't possible and for this fact I and other people are using that patch from Sierra ;)

 

PS

thank again to PMHeart to discover it for 10.13.4 beta

and for the sake of a right answer  I have answered here to your first request 

            #16745            

Link to comment
Share on other sites

XCPM seems to use secret tech, and it is described at the page I linked and you blocked. What is this, a kindergarten? Did t0nym4c also block links to you? LOL

 

I didn't block anything. lol, I'm pretty sure the link that it redirects to instead describes why it is blocked. It doesn't use secret tech, it just uses intel hardware features, there's a whole part of the developer's manual just for power management. It almost certainly uses monitor and mwait instructions.

Link to comment
Share on other sites

It was ironically meant. Not you in person, but you as insanely-team. Well, I find that blocking kindergarten like. Together you could reach much more , e.g. a proper wiki with always state of the art info. Whatever. Surely u know about that, only wondering that this is not the default clover setting for haswell... Since it seems to be faster, SSD seems to be snappier. Or I am just tired.

 

xcpm works here with and with cpu ssdts the same. And dual opencl is a Bliss.

Link to comment
Share on other sites

Hello, What is this in the code?:

  //dumping SETTING structure
  // if you change something in Platform.h, please uncomment and test that all offsets
  // are natural aligned i.e. pointers are 8 bytes aligned

Result:

0:100  0:000  Settings offsets:
0:100  0:000   OEMProduct:     218
0:100  0:000   DefaultVolume:  720
0:100  0:000   DefaultLoader:  728
0:100  0:000   ResetAddr:      748
0:100  0:000   FixDsdt:        7A4
0:100  0:000   FakeATI:        7B0
0:100  0:000   PatchVBiosBytes:7E0
0:100  0:000   VRAM:           830
0:100  0:000   SecureBootWhiteListCount: 860
0:100  0:000   LegacyBoot:     888
0:100  0:000   HVHideStrings:  8D0
0:100  0:000   PointerSpeed:   958
0:100  0:000   RtMLB:          980
0:100  0:000   ConfigName:     9A0
0:100  0:000   PointerSpeed:   958
0:100  0:000   PatchDsdtNum:   9E4
0:100  0:000   LenToReplace:   A00
0:100  0:000   ACPIDropTables: A10
0:100  0:000   CustomEntries:  A20
0:100  0:000   CustomTool:     A30
0:100  0:000   AddProperties:  A40
0:100  0:000   BlockKexts:     A48

Is that OK?

Link to comment
Share on other sites

 

 

It was ironically meant. Not you in person, but you as insanely-team. Well, I find that blocking kindergarten like. Together you could reach much more , e.g. a proper wiki with always state of the art info.

Uhm... The only guy I know there not only doing useless stuff is RehabMan and he is here too... Who *is* there even to work with on a wiki? Lol

Link to comment
Share on other sites

×
×
  • Create New...