[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[neocoma504]

I might be able to help with this.
Initially I also ran into this problem because by design, Yoda has to be running continuously given that it has to check for changes in temperature to adjust the fan and pump speeds.
This is in contrast to liquidctl, which dispatches its fan and pump profiles to the actual device, hence the script can quit once the data has been written. Of course that makes it very simple to run as a launch agent since it only has to run once and then quit.

With yoda, we have to take a slightly more advanced approach to run it as some kind of background service.
As a preface, I'm not an expert on how macOS operates and while my solution may work, it might not be optimal. Nevertheless, here we go.

Overall, I ran into two problems while trying to get Yoda to run as a background service:
1. Yoda has to run continuously
2. liquidctl may raise an OSError: Failed to open if we access the Kraken or the Smart Device too quickly

To circumvent 1. I made use a of a very useful little utility from Linux: screen
This command-line tool will allow us to create multiple "headless" terminal sessions in which we can run commands programmatically without having to bother with i.e. Terminal.app. I'm using this to dispatch my yoda commands into their individual shell environments where they can keep running indefinitely.
An added bonus is that we can attach to any of these sessions later on to check the output of the script, for example.

Tackling 2. is rather simple: We use the sleep command to wait a little between each command we issue to our cooling devices to prevent hammering the tiny embedded processors in them too much.

Wrapping this knowledge up in a script nets us something like this:

#!/bin/bash
# Init the Smart Device
liquidctl initialize -d 0
sleep 1
# Init the Kraken
liquidctl initialize -d 1
sleep 1
# Configure lighting (all off in this case)
liquidctl -d 0 set led color off
liquidctl -d 1 set ring color off
liquidctl -d 1 set logo color off
sleep 1
# Start Yoda for Kraken
screen -d -m -S yoda-kraken bash -c 'yoda --match "Kraken" control pump with "(60,40),(90,90)" on istats.cpu and fan with "(60,20),(90,50)" on istats.cpu'
sleep 1
# Start Yoda for Smart Device
screen -d -m -S yoda-smart-device bash -c 'yoda --match "Smart Device" control fan2 with "(60,30),(90,85)" on istats.cpu and fan3 with "(60,30),(90,50)" on istats.cpu'

Please take care to adjust the CPU temperatures and fan values to your system!
The ones shown here are exemplary and will likely only work well with my specific cooling setup and ambient temperature.

Save this script somewhere, i.e. in /Users/Shared/yodactl.sh, similar to what was done with the original liquidctl script.
Please note that this script will supersede liquidctl.sh as it handles the initialisation as well as the fan control!

We can now register a new LaunchAgent in /Library/LaunchAgents/.
Before doing this, please remove the original LaunchAgent for liquidtcl.sh, we won't need it anymore.
After this is done, we can register the new agent as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>liquidctl.sh</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/yodactl.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <false/>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
</dict>
</plist>

Note that I add the PATH environment variable to point to my Python installation. By default this should not be necessary, however if you have installed multiple versions of Python, i.e. using Homebrew, Pyenv, Conda or what have you, then you should tweak this path to primarily point to the location of the installation that actually has liquidctl installed.
In my case I am using Conda, so my path would have the first component: /usr/local/Caskroom/miniconda/base/envs/<conda_evironment_name>/bin

After setting everything up as described above, your cooling devices should be initialized a few seconds after login and yoda should be running and handling fan control.
You can verify this with two methods:
- Open Terminal.app and run: screen -ls
This should show you two screens with the names from the script and the status Detached
- Run a benchmarking tool like Cinebench to load the system and listen for the fans spinning up.
If they do, everything is working. If they don't, immediately abort the program to avoid overheating.

As a general note, the timing of the sleep calls could probably be shortened with some trial and error, but I find that these values work alright in most cases, so I didn't bother tuning them down to the minimum delay possible. Given that it's likely to differ from system to system, sticking with slightly higher sleep values seems the safer choice in my eyes.

Hi Byteminer,

I am building a Hackintosh with Kraken X52 which already works with liquidctl and have been very interested in using Yoda with iStats for relying on CPU temp directly.
But I struggle to get the script for Yoda launching correctly at startup. Maybe you can help me on this?
I will try to explain this the best I can with my bad English and light Bash skills...

-I installed "liquidctl" and "yoda" using "pip3 install" command (as recommended by Jonas to have the access to istats.cpu function) as well as istats
-I can correctly see kraken and sensors, and also send commands with liquidctl and yoda with responding fan/pump behaviour. Yoda is showing the istats.cpu temp with "show-sensors" command. The only thing different for "yoda" is that I have to specify the /usr/bin/yoda path to have the command working (maybe I didn't install at the right place?)
-I managed to have the LaunchAgent working for regular liquidctl, as explained in first page guide by @CaseySJ and it's working on startup, loading the fan and pump properties
-I followed your post about replacing this script by a script for yoda to run instead, removed the former liquidctl.plist in LaunchAgents and replaced by a new one. I've made some little changes because I don't care about the led color things and also I wanted to have a liquidctl settings applied before yoda in case this one fails at some point (I realised when doing some tests that when yoda execution was stopped the behaviour of Kraken was returning to the last profile that had been set with liquidctl)

Se here are my yodactl.sh script

#!/bin/bash
# Init the Kraken
liquidctl initialize
sleep 1
# Set base fan profile for Kraken
liquidctl set fan speed 20 35  30 40  40 50  50 60  60 80
sleep 1
# Set base Pump profile for Kraken
liquidctl set pump speed 20 50 60 100
sleep 1
# Start Yoda for Kraken
screen -d -m -S yoda-kraken bash -c '/usr/bin/yoda --match "Kraken" control pump with "(20,50),(80,90)" on istats.cpu and fan with "(20,30),(50,35),(60,40),(70,45),(90,80)" on istats.cpu'

And my yodactl.plist Launch Agent (which is same as yours)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>liquidctl.sh</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/yodactl.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <false/>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
</dict>
</plist>

As a result, when booting up, the scripts seems to load because I can hear that the liquidctl "base" profiles are applied, but the yoda part doesn't load (I can hear the difference in term of fan noise). The "screen -ls" command doesn't give me anything neither.
But if I open terminal and copy paste the command (#Start Yoda for Kraken), it works! I just don't understand why this doesn't work at startup load. I tried removing the /usr/bin path I added without change. Tried to remove the KeepAlive / False variable in the Launch Agent. Tried to increase the sleep command value to 2.

Any idea?
Thanks

 

[Mightymouseuk007]

I've been irked by this for a while as lately I've been struggling to obtain the performance numbers that I'd expect from my setup.

When I initially set up my build back on Mojave I got some pretty decent numbers in Geekbench and Cinebench, however since being on Catalina I fail to reproduce my initial results.
The only proper comparison I have at this moment is my Cinebench R20 result from my original post. Back then I managed 5624 points while now I'm sitting at about 5107, a very stark difference.

Unfortunately back then I used Geekbench 4 to test, so my recent Geekbench 5 results aren't directly comparable. However, to circumvent this issue and to prove to myself that I'm not going insane, I booted into Manjaro Linux to create a comparable Geekbench run outside of macOS but still on the same hardware.

Turns out that I'm consistently getting more performance in Geekbench 5 on Manjaro Linux than I do on macOS Catalina (10.15.4 Beta).
Runs on both systems were executed three times to account for warmup and only after the OS had settled down after startup to provide an even baseline. All BIOS settings remained the same throughout the testing.

You can find screenshots of my results in the attached image file. I've also included my GPU runs of both Geekbench 5 and LuxMark, though those are probably pretty standard for my Sapphire Nitro+ RX580.
Here is a detailed comparison of my Linux-vs-macOS Geekbench 5 results.

In addition, overclocking for me does not appear to affect my results on macOS in any major capacity. I'm running at 5.1GHz all core currently but I've also tried 5.2GHz as well as some lower frequencies, which had a rather negligible impact on my benchmark results. While the scores in Geekbench 5 somewhat scale with my frequency on Linux, my macOS scores appear to be "stuck" at the values mentioned above.

I've got no clue why this behaves as it does, my first guess would be Apple's power management somehow screwing with things. However, when I observe voltages and power draw via iStatMenus, the processor appears to reach full turbo on all cores and draws the amount of power that I'd expect, so the energy is definitely going in. As to where it then disappears to, I currently cannot fathom.

In my experience, this is more a "feature" of Geekbench on MacOS. Its not very reliable at all. In any event, synthetic benchmarks are never going give you a real world indication of performance. If you are trying to squeeze every last drop for the sake of benchmarks, then you are probably better off with a highly overclocked windows setup than MacOS. Again, in my experience - you results may vary

 

[gandem]

I have a dumb question here, does ram affect the memmap? More specifically- does more ram expand the memmap making it less likely to have allocation errors?

 

[neocoma504]

Hi @CaseySJ

First id'l like to thank you very much for this great guide you made and I just assembled a new Hackintosh with very close specs.

The install went very smooth and almost everything seems to work now. But I have two optional things that still give me hard time.

-First as explained in post #14,919 (page 1492) i got the 'liquidctl' script working for my Kraken X52, and launching at startup as expected. But i tried to make use of 'yoda' made by the same dev in order to make the Kraken fans react on CPU temp instead of internal liquid temp (which seems more reactive against the CPU usage). I can make 'yoda' work manually, but not loading automatically at startup, although the script is actually loading at startup (the script also contains 'liquidctl' commands before yoda command to set up a base profile in case 'yoda' background task fails). And what makes me mad is that the exact command in the script works if i use it manually in terminal. Did you give a try to yoda yet? Have any idea? The code i used for script and launch agent are in post #14,919.

-Secondly i had very hard time with the native nvram thing. I could remove EmuvariableUEFI.efi after using SSDT-NVRAM.aml and disabling CFG Lock with modified GRUB shell, but couldn't replace OSXAptioFix2Drv-Free2000.efi with OCquirks.efi and FwRuntimeServices.efi. This gave me the "couldn't allocate runtime area" every time. Tried with many OCquirks+FWruntimes versions (including the 'OCquirks-4' package from november and last one). Double checked the MSR 0xE2 register was disabled as well as the address following the UEFITool firmware check tutorial (i'm on firmware F9b). Did a CMOS reset + loaded optimized Bios Defaults + applied all Bios recommended settings + deactivate again CFG Lock, twice, with no more luck. Ultimately i found a solution by searching in older page of this thread with an intermediate version of OCquirks AND memoryallocation.efi (but cannot find the exact post anymore because search is giving me too many results with 'memory' and 'allocation' seperate...). This file allows me to boot without runtime allocation error and i think nvram is working (so far after many reboots the TestVar:Hello i wrote is still there).
But i can't get many info about this memoryallocation.efi. Is it safe to use all the time or is it more like a temporary trick? What does it do? Can i still consider i'm getting 'native' Nvram with it installed?

Thanks

Infos on my build :
macOS 10.14.6 18G3020 + Windows 10 1909 ; Clover v5104
Gigabyte Z390 Designare, Intel 9900k, 64gb Gskill TridentZ 3600 CL17, Sapphire RX580 Nitro+ 8GB, Kraken X52, Fenvi T919, Syba 10Gbe PCIe, 2 x Samsung 960 Pro 2TB + 2 x Samsung 860 Evo 2TB

I have a dumb question here, does ram affect the memmap? More specifically- does more ram expand the memmap making it less likely to have allocation errors?

I actually have the same question about RAM and memory allocation errors i got, but i'm using 64GB of Gskill TridentZ 3600CL17 memory, so i'm not sure this is matter of quantity, but maybe some other parameters depending of Ram used?

 

[byteminer]

Hi Byteminer,

I am building a Hackintosh with Kraken X52 which already works with liquidctl and have been very interested in using Yoda with iStats for relying on CPU temp directly.
But I struggle to get the script for Yoda launching correctly at startup. Maybe you can help me on this?
I will try to explain this the best I can with my bad English and light Bash skills...

-I installed "liquidctl" and "yoda" using "pip3 install" command (as recommended by Jonas to have the access to istats.cpu function) as well as istats
-I can correctly see kraken and sensors, and also send commands with liquidctl and yoda with responding fan/pump behaviour. Yoda is showing the istats.cpu temp with "show-sensors" command. The only thing different for "yoda" is that I have to specify the /usr/bin/yoda path to have the command working (maybe I didn't install at the right place?)
-I managed to have the LaunchAgent working for regular liquidctl, as explained in first page guide by @CaseySJ and it's working on startup, loading the fan and pump properties
-I followed your post about replacing this script by a script for yoda to run instead, removed the former liquidctl.plist in LaunchAgents and replaced by a new one. I've made some little changes because I don't care about the led color things and also I wanted to have a liquidctl settings applied before yoda in case this one fails at some point (I realised when doing some tests that when yoda execution was stopped the behaviour of Kraken was returning to the last profile that had been set with liquidctl)

Se here are my yodactl.sh script

#!/bin/bash
# Init the Kraken
liquidctl initialize
sleep 1
# Set base fan profile for Kraken
liquidctl set fan speed 20 35  30 40  40 50  50 60  60 80
sleep 1
# Set base Pump profile for Kraken
liquidctl set pump speed 20 50 60 100
sleep 1
# Start Yoda for Kraken
screen -d -m -S yoda-kraken bash -c '/usr/bin/yoda --match "Kraken" control pump with "(20,50),(80,90)" on istats.cpu and fan with "(20,30),(50,35),(60,40),(70,45),(90,80)" on istats.cpu'

And my yodactl.plist Launch Agent (which is same as yours)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>liquidctl.sh</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/yodactl.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <false/>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
</dict>
</plist>

As a result, when booting up, the scripts seems to load because I can hear that the liquidctl "base" profiles are applied, but the yoda part doesn't load (I can hear the difference in term of fan noise). The "screen -ls" command doesn't give me anything neither.
But if I open terminal and copy paste the command (#Start Yoda for Kraken), it works! I just don't understand why this doesn't work at startup load. I tried removing the /usr/bin path I added without change. Tried to remove the KeepAlive / False variable in the Launch Agent. Tried to increase the sleep command value to 2.

Any idea?
Thanks

You may enable logging for the LaunchAgent job by adding these values to the plist file:

<key>StandardOutPath</key>
<string>/Users/<your_name_here>/Desktop/yoda_std.log</string>
<key>StandardErrorPath</key>
<string>/Users/<your_name_here>/Desktop/yoda_err.log</string>

Naturally, change the path to include your actual username (or select an entirely different path, it's up to you).
This will create two files on your desktop which contain any output the script may produce. If anything within the script fails, the errors should appear in yoda_err.log.

In my experience, this is more a "feature" of Geekbench on MacOS. Its not very reliable at all. In any event, synthetic benchmarks are never going give you a real world indication of performance. If you are trying to squeeze every last drop for the sake of benchmarks, then you are probably better off with a highly overclocked windows setup than MacOS. Again, in my experience - you results may vary

It seems rather reliable in the sense that results are consistent. And it's not just geekbench but also Cinebench, which is typically very good at being comparable. it's a standard tool for a reason. I'm not really trying to win the benchmark race here, my concern is rather that there is an empiric performance degradation between the original Mojave system and the Catalina one and I'd like to figure out why that is. I'd find it rather strange to just accept that it's worse now, given the otherwise inquisitive nature people typically display in this thread.
Another suspicion I have is that some Intel security mitigations may have impacted performance, though I wasn't able to find much on the actual patch contents of supplemental macOS updates thus far.
In any case, it's not a super big deal, I was just curious whether anyone else was noticing the same thing, which at least cwoods seems to.

 

[CaseySJ]

I have a dumb question here, does ram affect the memmap? More specifically- does more ram expand the memmap making it less likely to have allocation errors?

In most cases additional memory will not affect the Memory Map. But in certain cases -- such as when multiple PCIe devices such as GPUs are present -- then "Above 4G Decoding" can use memory addresses above 4GB for memory-mapped I/O. Why above "4GB"? Because that's the boundary between 32-bit and 64-bit processing. A 32-bit processor can address physical memory up to 4GB (2 raised to the 32nd power).

Because most Designare Z390 owners are already using 8GB or more, adding even more memory will not affect the EFI Memory Map. But we should certainly enable Above 4G Decoding in BIOS Setup if using multiple PCIe cards.

 

[CaseySJ]

@neocoma504,

I'm finally budgeting time for liquidctl. Submitted the 1.3.3 update to Homebrew yesterday and it's now available via:

brew upgrade liquidctl

Will spend some time on yoda/iStats over the weekend.

Regarding MemoryAllocation.efi, it seems you might be one of the less than one-tenth of one percent who needs this!

• If using OpenCore, BIOS --> Internal Graphics should be disabled.
• If using Clover, Internal Graphics can remain enabled. But in some very rare cases, MemoryAllocation.efi is necessary. You may also try disabling Internal Graphics (temporarily) and booting without MemoryAllocation.efi.

 

[neocoma504]

You may enable logging for the LaunchAgent job by adding these values to the plist file:

<key>StandardOutPath</key>
<string>/Users/<your_name_here>/Desktop/yoda_std.log</string>
<key>StandardErrorPath</key>
<string>/Users/<your_name_here>/Desktop/yoda_err.log</string>

Naturally, change the path to include your actual username (or select an entirely different path, it's up to you).
This will create two files on your desktop which contain any output the script may produce. If anything within the script fails, the errors should appear in yoda_err.log.

Thanks for the answer.
Unfortunately the two log files i get are completely empty (opened with TextWrangler). But i really think my problem is related to the path used. Because i tried to load and unload several times the launch agent with making little changes in the script and at some point i got a launch with script functioning (including yoda command) by placing a 'cd /usr/bin' before the yoda screen command (and not inside). Unfortunately i was not able to reproduce this successful launch, don't know why... Also i realised that when using a simple "yoda -h" command outside of this /usr/bin path i got very different command help description. So i looked a little and found an other 'yoda' command in /usr/local/bin which seems to have nothing to do with our yoda! So maybe should i place the right yoda elsewhere or should i rename the right yoda command to avoid conflicts?

EDIT : I think i have a part of the answer for this issue. I started to reinstall everything (liquidctl/yoda/istats) in a virtual environment to be sure in can invoke every command without specifying the path. It's fine and all my manual commands inside the virtualenv are working (including the screen command). Then modified the launch agent plist to activate the commands inside the virtual env. As before this is working except for the yoda 'screen' command. Still no output on plist generated log files, but looking at /var/log/system.log i can see this very specific error at the exact time the screen command should launch : "com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Session adoption is only allowed in user domains." So i guess this command requires to be launched as user, not root. Problem is the plist launch agent needs to be owned by root, otherwise won't load. I don't know how to sort this out.

 

[elfcake]

At the moment, all my external hard disk are Thunderbolt 2. I will only have access to Thunderbolt 3 hard disk probably next week. I 'm using the Startech Thunderbolt 3 to Thunderbolt adapter.

The Thunderbolt 2 drives I'm using now and is hot plug-able are:
1) G-raid from G technology
2) OWC Thunderbay 4

@PicLock - I have a ThunderBay4. It is not Hot plug-able. Can you show me how you made this happen? Thank you.

 

[rj510]

I've been irked by this for a while as lately I've been struggling to obtain the performance numbers that I'd expect from my setup.

When I initially set up my build back on Mojave I got some pretty decent numbers in Geekbench and Cinebench, however since being on Catalina I fail to reproduce my initial results.
The only proper comparison I have at this moment is my Cinebench R20 result from my original post. Back then I managed 5624 points while now I'm sitting at about 5107, a very stark difference.

Unfortunately back then I used Geekbench 4 to test, so my recent Geekbench 5 results aren't directly comparable. However, to circumvent this issue and to prove to myself that I'm not going insane, I booted into Manjaro Linux to create a comparable Geekbench run outside of macOS but still on the same hardware.

Turns out that I'm consistently getting more performance in Geekbench 5 on Manjaro Linux than I do on macOS Catalina (10.15.4 Beta).
Runs on both systems were executed three times to account for warmup and only after the OS had settled down after startup to provide an even baseline. All BIOS settings remained the same throughout the testing.

You can find screenshots of my results in the attached image file. I've also included my GPU runs of both Geekbench 5 and LuxMark, though those are probably pretty standard for my Sapphire Nitro+ RX580.
Here is a detailed comparison of my Linux-vs-macOS Geekbench 5 results.

In addition, overclocking for me does not appear to affect my results on macOS in any major capacity. I'm running at 5.1GHz all core currently but I've also tried 5.2GHz as well as some lower frequencies, which had a rather negligible impact on my benchmark results. While the scores in Geekbench 5 somewhat scale with my frequency on Linux, my macOS scores appear to be "stuck" at the values mentioned above.

I've got no clue why this behaves as it does, my first guess would be Apple's power management somehow screwing with things. However, when I observe voltages and power draw via iStatMenus, the processor appears to reach full turbo on all cores and draws the amount of power that I'd expect, so the energy is definitely going in. As to where it then disappears to, I currently cannot fathom.

I have also noticed poorer performance testing on Catalina vs Mojave (this includes various mobos too).

I have no idea if this is related, but I've been dealing with a warning on Catalina startup that effectively says my computer is running on UPS backup battery. There is no UPS. I now realize that this error is due to the Corsair Commander PRO being accidentally recognized as a Commander Pro battery backup unit. (It is connected to an NZXT USB-2 hub, which in turn is connected to the USB2 mobo header.)

This error never occurred in Mojave. It seems that in Catalina, Apple is using the device name rather than the device-id (and vendor-id) to determine what's connected. (So far, I've been unsuccessful in fixing with a kext or SSDT.) This error prevents Time Machine from working, so other operations are impacted when the OS believes the power supply is less than optimum. And this error is still present in 10.15.4 beta.

Anyhow, is it possible that under Catalina some of our mobo connections (that is, other device- and vendor-id identification mistakes) are making MacOS think it's using something other than proper power management and this ends up throttling our builds when running under Catalina? Maybe investigating power management differences between Mojave and Catalina might be useful?