Same here. You sure about that? HT might not even be the best idea if you need to rely on those threads. Give it a try.
Cheers
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Cheers
AidenShaw
macrumors P6
One of the first things that I do when I get a new system is to disable hyperthreading - and I've done this since when HT first appeared.
On a case-by-case basis, I may enable hyperthreading. Those cases are when the system spends significant time with all physical cores busy. If you don't have significant periods of time with 100% CPU usage, hyperthreading can hurt your performance. Even if you do hit over 100%, hyperthreading is often only a mild benefit.
On Linux you can dynamically enable/disable logical CPUs by writing to the /sys filesystem.
echo 0 > /sys/devices/system/cpu/cpu113/online
will instantly remove logical CPU 113 from the system. The command
echo 1 > /sys/devices/system/cpu/cpu113/online
will put logical CPU 113 back online.
On a typical Linux system the "htop" command will show core usage. For example, it may show:
(For some reason, "htop" numbers CPUs from 1 to N, whereas most tools number them from 0 to N-1.)
In this screenshot, CPUs 1 to 72 are the "physical" cores, and CPUs 73 to 144 are the HT "second class" cores. (Core 73 is sharing core 1 resources.) If you iterate the command
echo 0 > /sys/devices/system/cpu/cpu$idx/online
from $idx=72 to $idx=143 - you'll instantly disable hyperthreading (until the next boot). Write a "1", and instantly the logical core is back.
I've tested quite a few workloads with and without HT using this technique - and HT is seldom a big win.
Also note that different systems enumerate cores differently. I think that Windows puts logical core 0 and logical core 1 on the same physical core (and logical core 142 and logical core 143 on the same physical core).
Last edited:
Don't forget you actually have to get hit with a payload for the vulnerability to matter. For that to happen you have to be exposed to malicious code, like being tricked into opening a trojan or visiting a website with an attack script. This isn't a new, innovative way for malicious code to be delivered to a machine, just a new thing malicious code can do once it's been downloaded and executed. Reading news reports on these vulnerabilities makes it sound like a hacker just needs to sneeze at your machine to break in, which isn't necessarily true.
- Is your web browser up to date?
- Do you have an adblocker extension installed? (to prevent malvertising attacks)
- Xprotect definitions up to date?
- Is your Mac behind a router with a firewall?
- Do you avoid visiting shady websites?
- Do you carefully vet the source of the software you download?
handheldgames
macrumors 68000
FWIW... I have about 0% chance of disabling hyper-threading. Safari and chrome have both patched for zombieload. The 4,1/5,1 is slow enough... Disabling hyper-threading? I might as well recycle the aluminum chassis.
That is really interesting and you have me looking at this different now. A lot of my software and particularly plugins utilize distributed processing across multiple cores. I'll have to try disabling HT while running a large session with a lot of plugins and see if it's the same CPU performance if not better.
[doublepost=1558142342][/doublepost]
Actually, what worried me most was the vulnerability was demonstrated attacking a computer running the current version of TOR browser within a VM instance of Tails. Just goes to show with the right set of skills a hacker will achieve their payload regardless of most basic security implementations. I guess these Intel processors are just RIDL'd with security holes😛
I think that was a bit of dramatic flair on the researchers' part. If something as low level as the CPU is compromised then it doesn't matter if the target is Notepad.exe or a TOR browser running in a VM. But once again, in order to pull off that neat trick the attacker needs to successfully circumnavigate multiple layers of security and hit your machine with a payload that exploits the vulnerability, not to mention consider you a worthwhile target for all the effort. Entities that should be worried about this would include governments, large corporations and data centers - the most likely targets for a sophisticated information espionage attack.
To conclude, disabling hyperthreading on a Mac used in a home or small business seems really unnecessary if you follow basic internet security practices.
That's what I was trying to get at. But as always: YMMV
You can change that in the settings.
Are we getting too off-topic here...?
Cheers
yager
macrumors newbie
Could be wrong, but I cannot see Intel staying the course and refusing to update the microcodes for the X56 proc regardless what they put in print. Why, this was one of the main procs in the HP 360/380 line for the 5520 chipset in the G7s. There are a lot of G7s out there in data centers all over the world still running and still under extended warranty by HP. Yes, you would be surprised. Unless Intel is willing to assist HP and not Apple. There would be too much blowback coming out of this vulnerability and Intel sitting on their hands. Maybe Intel seen Apple had so much fun on their planned obsolescence class action suite, Intel wanted to get in some of that action too.
I hope that I'm wrong, but I'm inclined to think that Intel announced that they don't plan to issue microcode corrections for Nehalem and Westmere Xeons to force enterprise upgrades for servers with these processors still in use.
Intel will get a lot of enterprise blowback and probably some from angry workstation users, that they effectively don't care, but a lot of CTOs will think that's the time of upgrading anything Nehalem/Westmere anyway and thats the push they need to justify spending the money.
The financial gains will be more than the blowback and thats what Intel wants. They care zilt for Mac Pro users.
Now let's go back to the usual BootROM topics.
flehman
macrumors 6502
In case this info is helpful to anyone. I am on a 4,1->5,1 with a MVC-flashed GTX 980 and still on HS 10.13.6 due to lack of drivers for Mojave. I was still able to download the Mojave full installer and run the 144 BootROM upgrade. I guess the installer doesn’t check the GPU too closely during the BootROM upgrade.
h9826790
macrumors P6
It checked your GPU. 980 is a Metal supported GPU. You can check your system info.
In HS, when web driver is loaded, Metal is available. That’s why Mojave installer can trigger the firmware update.
If you make a Mojave USB installer (or even simply disable web driver in HS), and use the Mac EFI UGA Display ability to run the installer. There will be no Metal support GPU detected, and the firmware update won’t be triggered.
It’s a matter of if web driver / Metal available in your current OS, not Mojave.
Last edited:
flowrider
macrumors 604
Thanks for your post, but it's posted in the wrong thread. Many of use have done what you describe, it's detailed in this thread:
https://forums.macrumors.com/thread...-mojave-bootrom-upgrade-instructions.2142418/
Personally I am running an MVC flashed GTX 1080 in 10.13.6 (17G7024).
Lou
FWIW, with the 144 firmware and the NVRAM settings to disable HyperThreading, my Windows 10 UEFI installation (yes I know, I know) is unstable. It intermittently freezes on the Windows logo at the beginning of the boot sequence, before the spinning wheel, and goes no further. When it does boot successfully, it shows HyperThreading disabled, as others have pointed out. If I reset the NVRAM to clear out those settings, Windows goes back to being stable again.
I’m not sure if reinstalling Windows with those NVRAM settings in effect would help, but I just reinstalled Windows for other reasons so I’m not super keen on doing that. I’m also afraid to mess with it too much more, since I think it’s freezing right around when the SecureBoot/certificate stuff happens, and I know that is already a known problem area for these machines...
I’m not sure if reinstalling Windows with those NVRAM settings in effect would help, but I just reinstalled Windows for other reasons so I’m not super keen on doing that. I’m also afraid to mess with it too much more, since I think it’s freezing right around when the SecureBoot/certificate stuff happens, and I know that is already a known problem area for these machines...
I´m curious about How many users ara disabling HT. In my case, not a chance.
Not for me right now as I'm doing a bunch of Handbrake encoding. Perhaps I will when I'm done with that project.
Also not for me. This is just crazyness! It's like buying a Ferrari then limiting it to 100 km/h for safety reasons.
Norbert Mikołajczyk
macrumors 6502
intel give me a discount on new Mac Pro or just do what you need to do and patch the cpus!!!
I'm so angry at them that I really can't imagine to buy new pricey Mac Pro with cpus from them.
I would rather switch to amd.
My current beefed Mac Pro is doing just fine and the new AMD VII GPU will expand its possibilities even more with hardware H265 support.
I'm so angry at them that I really can't imagine to buy new pricey Mac Pro with cpus from them.
I would rather switch to amd.
My current beefed Mac Pro is doing just fine and the new AMD VII GPU will expand its possibilities even more with hardware H265 support.
crjackson2134
macrumors 601
We already have a poll going.
https://forums.macrumors.com/thread...-patching-for-older-macpros-now-what.2181576/
Today @orph sent his mid-2010 dump to check, his Mac Pro can't boot W10 anymore. His NVRAM is a mess and I had to improve my signature file to just to parse the dump.😱
Signature version 8:
- Multi MemoryConfigs, 25 entries.
- 12 PanicInfoLogs (Kernel Panics) with a different format than what I usually found in previous dumps
- 2 IASInstallPhaseList logs,
- 3 IASCurrentInstallPhaseBoot logs.
Signature version 8:
- corrects the start of 1st and 2nd NVRAM stream,
- implements logic checks to detect and show 11 and 12-digits SSN,
- implements logic checks to detect and show 3 and 4 digits HWC,
- correctly detects the second format for Kernel Panics, calling it B for now.
Today Apple re-issued:
[doublepost=1558403757][/doublepost]No firmware changes, btw.
- 10.14.5 combo/delta,
- Security Update 2019-003 for 10.12.6,
- Security Update 2019-003 for 10.13.6
- iTunes Device Support
- 18F132 build for 10.14.5
- 17G7024 for Security Update 2019-003 for 10.13.6
- 16G2016 for Security Update 2019-003 for 10.12.6
[doublepost=1558403757][/doublepost]No firmware changes, btw.
Last edited:
Earl Urley
macrumors 6502a
TheStork
macrumors 6502
Does this mean we should manually download the updated updates and re-install them? Are the build numbers different on the newer updates?