Show HN: Turbo Boost Disable for macOS
github.comI know it's not protocol to talk down Show HN submissions. But this is just a shell script loading a core component of TBS [0] during login without password prompts: by saving your password in a plain text file.
I can agree that password prompts at login are not the best user experience but security is there for a reason.
Maybe TBS should implement this using the privileged helper pattern [1] which allow a small daemon with root permissions to perform actions for a userland application through a secure RPC channel.
[0] https://github.com/rugarciap/Turbo-Boost-Switcher
[1] https://developer.apple.com/library/archive/documentation/Se...
[2] https://developer.apple.com/documentation/servicemanagement/...
Well, it also loads a random kernel extension that is only there as a binary blob that the author didn't make.
> I know it's not protocol to talk down Show HN submissions. But this is just a shell script loading a core component of TBS [0] during login without password prompts: by saving your password in a plain text file.
And TBS itself is (self-admittedly) largely a graphical wrapper around this kernel extension: https://github.com/nanoant/DisableTurboBoost.kext
TBS's Pro version uses a privileged helper, says so in the readme. :)
This is not at all meant to be a criticism, but more a question: is taking a 20% performance hit, as the author writes, really worth it for a theoretical improvement in the lifespan of some integrated circuits? Are ICs actually how modern laptops break?
What do you think the odds are in him realising this benefit? Assuming he bins the laptop after, say, 5 years? (he's rich enough to buy a £1.3k minimum laptop, assuming it wasn't second hand)
It relies on several assumptions: 1) His laptop dies before he bins it in 5 years' time 2) It died becuase of an integrated circuit (the reason he cites) - in my experience old computers tend to die of things like exploded motherboard capacitors rather than ICs. Maybe the death of these are accelerated by turbo boost, too? 3) The integrated circuit's death was hastened by a meaningful amount (several months at least; a dodgy thing dying a couple of days/weeks later doesn't save you from buying a new laptop).
Is taking a 20% performance hit on your laptop really worth this? I'm interested. I can't imagine it would be for the vast majority of people.
Generally the packaging fails well before the integrated circuits themselves do. Thermal stress is hell on SMD and BGA solder joints, and you can't reach ~100C temperatures routinely without quite a bit of thermal stress.
But 100C is also pretty much Tjunction temperature anyway, which means reaching that temp will in fact cause physical wear and tear on the IC. The wear and tear would probably decay exponentially as you drop away from the Tjunction limit, but that still means you don't want to get too close to it in general.
It seems highly unlikely to me that the CPU running hot does it any harm. Intel turbo boosts up to 100C and starts thermal throttling there because that's what they designed the chips for. Maybe other parts will break because of too much heat around the laptop; if it's on a desk made out of PLA or something, you'd want to keep the computer as cold as possible. Maybe the heat melts the adhesive holding the battery in place and it starts rattling around. Maybe the heat ruins the keyboard. I have never heard of any of these happening... but who knows.
The reality is that what seems "pretty warm" to your hand is nothing to a computer. 100C is hot for them. Dip your hand into some freshly boiled water. Is your computer that hot? Then it's fine. (Don't actually do this.)
It is also unclear to me that disabling frequency scaling results in a cooler computer. Someone should collect some data on how the power is actually used; does it use less power to perform a calculation for 2 seconds at 1000MHz or 1 second at 2000MHz?
Finally, my experience with overclocking is that it's AVX that really makes Intel chips heat up, regardless of frequency.
All in all, I think this probably does nothing. Personally I just use an iPad Pro as a laptop and keep my computers in a datacenter. No fans.
The main problem is really the heat/battery life—my laptop has a 6-core processor inside it with seriously inadequate cooling performance (with it being so thin). I guess the lifespan argument is technically be true but isn't the main reason I disable TB.
The 20% is worth it for me because the computer seems to be fast enough anyway.
I use it (the turbo boost switcher by rugarciap) because of the increased battery life, decreased battery wear (frame gets less hot) and more silent fan. This is on a 2012 MBA which is still doing very fine as my daily driver (except for the display joint getting quite soft)
Relevant quote for those wondering how it’s done:
> This is just a shell wrapper around a kext to disable Turbo Boost on 64-bit macOS, taken directly from TBS.
> We have to use the direct TBS kext because for some reason, their kext can run on macOS, but we cannot sign our own version to work on macOS. They must have signed it with an Apple key or something? Anyway, to get around having to use the crappy Turbo-Boost Switcher GUI, we take the core kext, which is directly enabled/disabled with the shell scripts in this repo.
The kext in question is from this app:
https://www.rugarciap.com/turbo-boost-switcher-for-os-x/
The benefits of disabling Turbo Boost can be studied more closely at this prior post about Turbo Boost (28 days ago, 6 dupes, 0 comments):
https://marco.org/2020/01/13/macos-low-power-mode-redux
-62% power draw (Watts), +59% build duration (seconds), -28% heat levels (Celsius)
Looks neat! Shouldn't there be a better way to get the required permissions than asking the user to put their login password in a plaintext file?
There's likely a way to get root without having to read the password each time, this is just what I managed to hack together. If anyone has any ideas/suggestions I would be happy to fix this ASAP!
Allow the script to run under sudo without a password.
Looks like the author already addressed this - the README now has instructions on configuring /etc/sudoers to run the script without requiring the user’s password. See https://github.com/bradleymackey/turbo-boost-disable/issues/... although https://github.com/bradleymackey/turbo-boost-disable/issues/... points out another security hole with that approach.
You could do this as a launchd service, which will run as root and will happen automatically with startup. No sudo nor brew required.
See /Library/LaunchDaemons and launchctl.
There are some hints that a “Pro Mode” might be coming in macOS[1] that unlocks power in exchange for fan noise, etc. I wonder if that could be extended into a “battery saver” node like iOS has that does effectively the opposite?
[1] https://9to5mac.com/2020/01/13/macos-beta-hints-at-future-pr...
I hope something like this comes soon. Until then, I'll keep my Turbo Boost disabled!
I’m not an OSX expert, but it seems like you should be able to make a compiled binary to do this and then give it setuid permissions, avoiding the need for a password. At least that is how I would do it on other unixes.
Out of curiosity, can you not get some of these benefits by simply running your fan more / at lower temperatures and instead sacrifice a bit of noise instead of the performance?