Have you been able to update an existing lightweight macOS Virtual Machine on Apple silicon to Sequoia 15.4? So far, I’ve had three failures ending in kernel panics, and no successes. Maybe I’m holding it wrong?
Good news …
I’ve had no problems updating VMs from Sonoma 14.7.4 to 14.7.5, or Ventura 13.7.4 to 13.7.5. Those updates went quickly and without a glitch, but Sequoia has been another matter.
… bad news
I’ve now tried to update from Sequoia 15.x to 15.4 with three different VMs:
freshly installed 15.2
freshly installed 15.3.2
lightly used 15.3.2.
None of them had iCloud enabled, but they were each fairly standard in other respects, and all running in Full Security mode, in my virtualisers Vimy and Viable.
Each has failed early, just a minute or two after the update started to install. That was terminated, and the VM briskly rebooted back into its existing version of Sequoia. Shortly after logging back in, they displayed the panic alert.
One VM was so sick at that stage it couldn’t go any further, so had to be humanely destroyed. However, I managed to capture panic logs for the other two. In both cases, the panicked task was com.apple.Mobile, with com.apple.iokit.AppleVirtIOStorage(1.0) at the top of the kernel extensions in the backtrace. The panic occurred on different cores, and its cause was given as “Kernel data abort”.
And a more innocent bug
In the course of looking at this, I happened to notice that creation dates of files in Shared Folders were all incorrect, giving a standard date of Monday, 1 January 2001 at 00:00. All other creation dates in VM folders, the SSV, and even in iCloud Drive folders, were as expected, but none of those in Shared Folders.
However, when any of those mis-dated files or apps were copied into the VM’s local storage, the expected date of creation returned like magic.
I have checked this in VMs running 15.2, 15.3.2, 15.4, 14.7.5 and 13.7.5, and it’s identical in every one. I suspect this may have been going on for some time. Am I holding this one wrong too?
Over to you
Have you been able to update a Sequoia VM to 15.4?
Are file creation dates wrong in your VM’s Shared Folders?
Postscript
Thank you all for your responses. I’ve now confirmed that failure to update to 15.4 appears confined to M4 models, and doesn’t afflict my MBP M3 Pro at all. However, the shared folder creation date bug seems just the same there.
Most modern Macs start up from their internal SSD, and have a single bootable system installed. Although its structure has changed considerably over recent years, and differs between Intel and Apple silicon Macs, they are generally reliable, and knowledge of their structure and function is seldom required.
Those who need to start their Mac up from two or more versions of macOS, or who do so from an external disk, may be able to get by without deeper understanding, but the moment there’s a problem can become confused, and end up having to install macOS from scratch.
Intel T2 and Apple silicon
Both types of Mac are designed to support Secure Boot, but because of the reliance of Intel Macs on UEFI firmware, they can only boot securely from their internal SSD. Enabling an Intel T2 Mac to start up from an external disk thus requires its boot security to be reduced by changing that in Startup Security Utility, in Recovery mode. Booting from an external system is then straightforward, and doesn’t require additional security measures as used in Apple silicon.
Apple silicon Macs have been designed from the outset to support Secure Boot when starting up from both internal and external disks, and don’t require any reduction in their boot security to be able to start up from multiple systems on external SSDs. It’s a common misunderstanding that trying to change Boot Security in Startup Security Utility can help solve Apple silicon boot problems, but if anything it only complicates them. Almost the only good reason for reducing boot security of an Apple silicon bootable system is when third-party kernel extensions are required. Otherwise don’t tamper with Startup Security Utility, as it will only confuse, as we’ll see later.
For an Apple silicon Mac to boot from a macOS system, that must have a LocalPolicy created and saved to the internal SSD. LocalPolicy is normally created during macOS installation, or when intending to start up from a suitably installed system. Problems with LocalPolicy have been common when using external disks, and are covered in these articles:
Another significant difference between Intel and Apple silicon Macs is the architecture of their internal SSDs: Apple silicon has two additional partitions (APFS containers), and lacks the traditional EFI partition. However, there are no such differences in the structure of their bootable external disks, and its relevance here is limited, and mainly affects Big Sur as I explain below.
macOS 10.13-10.15
Bootable disks in versions of macOS between High Sierra and Mojave (above) are based on their single boot volume, supplemented by hidden Preboot, Recovery and VM volumes. macOS 10.15 Catalina (below) divided that boot volume into a Boot Volume Group, consisting of paired System and Data volumes, in addition to the same three hidden volumes.
Basic support for volume roles was introduced in the first release version of APFS in macOS 10.13, and was extended to cover further roles in 10.15. Thus versions of APFS prior to 1412.x.x don’t understand volume roles used by subsequent systems. From Catalina onwards you can use the command diskutil apfs listVolumeGroups
to see paired System and Data volumes, for example +-- Container disk5 5BA1AAC8-3AD4-4594-AF01-7C0AA75CABAD
| |
| +-> Volume Group 68627CBB-D774-444E-97C6-F9511B5030F3
| =================================================
| APFS Volume Disk (Role): disk5s1 (Data)
| Name: Macintosh HD - Data
| Volume UUID: 68627CBB-D774-444E-97C6-F9511B5030F3
| Capacity Consumed: 580769214464 B (580.8 GB)
| -------------------------------------------------
| APFS Volume Disk (Role): disk5s5 (System)
| Name: Macintosh HD
| Volume UUID: 8B9FF440-75C8-4F7F-B09E-9222D44A2276
| Capacity Consumed: 11239186432 B (11.2 GB)
Note that each volume group has its own UUID, which is normally the same as that of the Data volume in the pair. Identification of volumes, containers and other structures in APFS is dependent on these UUIDs, which are an essential part of the GUID Partition Table scheme used to partition disks.
Catalina’s System volume is mounted read-only, but macOS is booted from that volume rather than the Signed System Volume snapshot introduced in Big Sur.
macOS 11
Although the structure of Big Sur internal SSDs in Apple silicon Macs has two additional partitions (APFS containers), Apple_APFS_ISC containing three volumes, and Apple_APFS_Recovery containing two volumes, bootable external disks have the same structure as the internal SSD in Intel Macs.
One important functional difference, which remains relevant to Big Sur boot disks, is that Apple silicon Macs don’t use the paired Recovery volume as their primary Recovery system: booting an Apple silicon Mac running Big Sur into Recovery should instead use the Recovery system installed in their internal SSD, in the Apple_APFS_Recovery partition. In subsequent versions of macOS, that’s used instead for secondary or Fallback Recovery. Thus Big Sur can be a problem when it comes to Recovery, and for this reason is best avoided on Apple silicon Macs. If it’s essential to install a copy of Big Sur, then be prepared for problems with Recovery mode.
macOS 11 also established the architecture for dual-boot partitions, with two or more Boot Volume Groups.
Although the Boot Volume Group has only ever referred to paired System and Data volumes, within each partition/container the group also requires three or four additional volumes, for Preboot, Recovery, VM and (apparently in Big Sur only) Update. How those work with multiple Boot Volume Groups is explained below. Once way to avoid the inevitable complexities is to install each Boot Volume Group into a separate partition/container, which provides each with its own suite of Preboot, Recovery and VM volumes.
As the Signed System Volume (SSV) was introduced in macOS 11, versions of APFS prior to 1677.x.x shouldn’t be expected to understand SSVs.
macOS 12-15
The next significant architectural changes in Apple silicon Macs were the introduction of paired Recovery volumes in macOS 12 Monterey, and of cryptexes in macOS 13 Ventura.
In macOS 11 and 12, Safari, its supporting components, and some other parts of macOS are installed to the Data volume for ease of maintenance. Apple replaced that with separate secure disk images termed cryptexes, loaded from the Preboot volume during the boot process and grafted into the root file system. As a single Preboot volume can be shared by more than one Boot Volume Group, bundled cryptexes must be provided to the correct group, and I suspect that’s accomplished by associating them with their Volume Group UUID. If that becomes confused in any way, cryptexes could be incorrectly associated or missing altogether, something that’s almost certainly fatal to the boot process.
Above is the current layout of a partition/container containing a single bootable system for a Mac running Sequoia. Device names given are illustrative, although their numbering is typical of that seen for external bootable volumes. In this instance, the base name for the Boot Volume Group is External, and the External System volume is unmounted as usual.
Below is a typical partition/container containing two bootable systems named ExternalA and ExternalB. This has two Boot Volume Groups, each consisting of a System volume with its SSV, and a Data volume, to which are added their three common volumes, Preboot, Recovery and VM.
Management
Creation
The most reliable tools for creating and working with Boot Volume Groups and other system components are those in macOS installer apps, and even they can have their moments and bugs. It’s usually possible to ‘clone’ groups using the asr command tool, a feature that’s offered in some third-party utilities including Carbon Copy Cloner and SuperDuper. However, Apple has made it clear that given a choice between supporting asr and addressing boot security, it gives the latter absolute priority. asr has suffered some serious bugs since the SSV was introduced in Big Sur, and shouldn’t be relied on.
asr is careful to ensure that, when cloning Boot Volume Groups, UUIDs are changed so that it doesn’t end up with volumes or groups with the same UUID. That may not be the case when using some other tools such as dd for duplication. If you prefer a simple and stress-free life, it’s better to put your trust in a macOS installer rather than try crafting your own Boot Volume Groups.
Apple’s own tools such as Disk Utility now try to steer the user away from making mistakes, such as deleting just one of a Boot Volume Group, leaving the other orphaned with its firmlinks broken.
Firmware
Firmware is another source of confusion. That installed in the Mac, using its internal storage, should always reflect the firmware that has been included in the most recent version of macOS installed or updated on that Mac, whether that was installed to the internal SSD or to an external disk. The only exception to this is when installing or updating macOS in a Virtual Machine, which can’t affect the host’s firmware.
What may appear more puzzling are the versions reported in System Information: that given as System Firmware should be the iBoot version for the main Mac, and the most recent. The OS Loader, though, varies with the Boot Volume Group, and in older macOS is likely to be earlier than the iBoot version of the main Mac.
Recovery
Recovery system versions are even more complex. When everything works as it should, the version installed in any paired Recovery volume should be the newest of the Boot Volume Groups that it’s paired with, in the same partition/container. If a Mac running 15.3 from its internal SSD has a bootable external disk with a single container with two Boot Volume Groups for 13.7 and 14.7, then the Recovery system for the internal SSD should be 15.3, while that shared by the two systems on the external disk should be 14.7. It’s likely that Fallback Recovery on the internal SSD will be from an earlier version of macOS 15, but that’s less predictable, and there’s no separate Fallback Recovery in external systems.
Switching between systems and their Boot Volume Groups is normally performed using Startup Disk in General settings, or its equivalent in System Preferences. Those record the chosen Boot Volume Group in NVRAM, from where it’s used during the next boot.
That setting is used to determine which Recovery system is used if the next boot is performed with the Power button pressed to enter Recovery mode. That in turn determines what can be performed in Recovery. This is most critical for determining how Startup Security Utility works, as that can only change boot security settings for the chosen Boot Volume Group saved in NVRAM.
For example, in the dual-boot container shown above, selecting ExternalB as the Startup Disk, shutting down, then starting up into Recovery mode should enable Startup Security Utility to control boot security for ExternalB but not ExternalA, nor the system installed on the internal SSD. This can be used to discover which Recovery system is running: open Startup Security Utility and the only boot system that can be changed there is the current default boot system.
APFS
Although APFS should be backward compatible, making it relatively safe to make changes to an older version of APFS from a newer system, forward compatibility is more limited. Using older versions of Disk Utility or tools like fsck on newer versions of APFS risks errors, failure and at worst damage. The Appendix at the end of this article summarises version numbering in APFS and major changes to beware of. Although not easy to discover the version of APFS used to create or modify any given volume, one way is to use fsck_apfs -n -S [device]
giving the volume’s device name. The report should then be prefaced by a statement such as The volume [volume name] was formatted by diskmanagementd (1412.141.1) and last modified by apfs_kext (945.250.134).
telling you that volume was created by macOS 10.15, and was last changed by macOS 10.14.
Troubleshooting
The first and fundamental step in trying to diagnose the cause of problems with multiple Boot Volume Groups or bootable external disks is to examine their container and volume structure using two diskutil commands: diskutil apfs list
lists all APFS volumes by container and gives key information about each, including role and UUID, and diskutil apfs listVolumeGroups
lists all recognised Boot Volume Groups, which you can tally against the first. Pipe these to text files so you can study and refer back to them.
Those should enable you to verify that the structure is as intended, and to establish the relationships between systems and paired Recovery volumes. From there you should be able to focus on the Boot Volume Group that’s misbehaving, ensuring that its Data volume has been backed up. If necessary, that can be used as a migration source if that group needs to be deleted and reinstalled.
Tips & tricks
The host Mac must be capable of running that version of macOS.
macOS installers are the most reliable means of creating and installing Boot Volume Groups.
During macOS installation, an external disk must be connected to a port other than the DFU port, as listed here and in Mactracker.
When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
Boot from an installer volume through Recovery mode.
When using a laptop Mac, run it from mains power throughout macOS installation.
Apple silicon Macs boot from external disks in Full Security, and reducing that doesn’t solve any problems.
Each container with one or more Boot Volume Groups contains one set of Preboot, Recovery and VM volumes shared between them.
If you’re unsure which Recovery system you’re using, open Startup Security Utility, as the only group it can change settings for is the one it’s booted into.
Big Sur doesn’t support paired Recovery on Apple silicon, and that can cause problems.
The version of Recovery installed in any paired Recovery volume should be that of the newest of the Boot Volume Groups that it’s paired with.
Use fsck_apfs -n -S [device] to discover the APFS version.
Use diskutil apfs list and diskutil apfs listVolumeGroups to discover volume structure.
Try using a Virtual Machine instead, if you don’t need to be able to run software from the App Store.
Appendix: APFS version numbers
APFS major version numbers change with major version of macOS:
macOS 10.12 has APFS version 0.3 or 249.x.x, which shouldn’t be used at all.
10.13 has 748.x.x, which doesn’t support Fusion Drives, but has basic support for volume roles.
10.14 has 945.x.x, the first version to support Fusion Drives.
10.15 has 1412.x.x, the first version to support the multi-volume boot group, and introduces extended support for volume roles, including Data, Backup and Prelogin.
11 has 1677.x.x, the first version to support the SSV, and Apple silicon. On M1 Macs, it doesn’t support the paired Recovery volume.
12 has 1933.x.x until 12.2, thereafter 1934.x.x, which support the paired Recovery volume on Apple silicon.
13 has 2142.x.x, and is probably the first to support trimming of UDRW disk images and their storage as sparse files.
14 has 2235.x.x, until 14.3, thereafter 2236.x.x.
15 has 2313.x.x until 15.2, thereafter 2317.x.x until 15.4, thereafter 2332.x.x.
Installing macOS on external bootable disks connected to Apple silicon Macs has been one of the most frustrating experiences of my life, and has driven some more experienced than me to abandon their attempts altogether. The latest bug in this was reported by Michael Tsai earlier this week, and can prevent you from installing any version of macOS prior to Sequoia, on an external disk connected to an Apple silicon Mac running macOS 15.3.2, and likely earlier versions of Sequoia.
To reproduce this, I partitioned an external 2 TB SSD connected to my MacBook Pro M3 Pro, which originally shipped with Sonoma 14.1. I have on many occasions installed macOS on that SSD for use with Apple silicon Macs, and hadn’t had a failure with it. To ensure favourable winds, I connected the SSD to the USB-C port at the right of the left side of the case, which isn’t the designated DFU port.
Apple disables installers for previous major versions of macOS from running in more recent versions. Trying to run a Sonoma installer in Sequoia is therefore doomed to fail. Instead, the installer has to be converted into a bootable installer volume, and the Mac booted from that to perform the installation. Although you can use a USB ‘thumb’ drive for that purpose, I prefer to use a 100 GB partition on a convenient external disk, in this case the same SSD on which macOS was to be installed. One of the quirks of bootable installers is that they must still use HFS+ rather than APFS, hence they get a partition of their own.
The three partitions I created were:
APFS container with two APFS case-insensitive unencrypted APFS volumes in 900 GB
APFS container with one APFS case-insensitive unencrypted APFS volume in 1 TB
HFS+ Journaled volume in 100 GB.
I used two Sonoma full installer apps, one for 14.6.1 taken from my library, the other for 14.7.4 freshly downloaded from Apple, both installed from InstallAssistant packages into /Applications. Each was successfully installed individually into the HFS+ volume on the external SSD following the instructions given by Apple.
In each test, I entered the external installer from Recovery mode as detailed by Apple, and started installation to one of the two APFS volumes in the first APFS container on the external SSD. After long periods attempting the installations, both failed with exactly the same error reported by Michael Tsai: com.apple.OSinstallerSetup.error error 702
Between the two attempted installations, both the HFS+ volume and the destination APFS container were erased and set up again. Following those two failures, I successfully installed macOS 15.2 and 15.3.2 direct to the three APFS volumes on the external SSD without any problems, and verified that all three Sequoia installations had been completely successful.
I therefore conclude that, in Sequoia 15.3.2 at least, it’s not possible to install any version of macOS prior to Sequoia 15.0 on an external SSD connected to an Apple silicon Mac. If your experience differs, then please let me know how you did it.
Michael Tsai appears to have been successful only when running the installation from Sonoma. If you do need access to a non-virtualised installation of Sonoma or earlier, it appears the only way you’re likely to succeed is from Sonoma, which would require you to perform a full DFU Restore to revert the Mac to macOS 14.
Useful tricks
The Mac must be capable of running that version of macOS.
The external disk must be connected to a port other than the DFU port.
When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
Boot from the installer volume through Recovery mode.
When using a laptop model, run it from mains power throughout macOS installation.
If essential, you can revert the Mac’s internal SSD to an older version of macOS and firmware using a full DFU Restore with an appropriate IPSW image file.
Use a Virtual Machine instead, if you don’t need to be able to run software from the App Store.
With more new M4 Macs in the offing, one question that I’m asked repeatedly is whether you should save money by getting a Mac with the smallest internal SSD and extend that using cheaper external storage. This article considers the pros and cons.
Size and prices
In Apple’s current M4 models, the smallest internal storage on offer is 256 GB. For the great majority, that’s barely adequate if you don’t install any of your own apps. It might suffice in some circumstances, for example if you work largely from shared storage, but for a standalone Mac it won’t be sufficient in five years time. Your starting point should therefore be a minimum of 512 GB internal SSD. Apple’s typical charge for increasing that to 2 TB is around $/€/£ 600.
The alternative to 2 TB internally would be an external 2 TB SSD. Unless you’re prepared to throw it away after three years, you’ll want to choose the most versatile interface that’s also backward compatible. The only choice here is Thunderbolt 5, which currently comes at a small premium over USB4 or Thunderbolt 3. Two TB would currently cost you $/€/£ 380-400, although those prices are likely to reduce in the coming months as TB5 SSDs come into greater supply.
Don’t be tempted to skimp with a USB 3.2 Gen 2 external SSD if that’s going to be your main storage. While it might seem a reasonable economy now, in 3-5 years time you’ll regret it. Besides, it may well have severe limitations in not Trimming as standard, and most don’t support SMART health indicators.
Thus, your expected saving by buying a Mac with only 512 GB internal storage, and providing 2 TB main storage on an external SSD, is around $/€/£ 200-220, and that’s really the only advantage in not paying Apple’s high price for an internal 2 TB SSD.
Upgrading internal storage in an Apple silicon model currently isn’t feasible for most users. As Apple doesn’t support such upgrades, they’re almost certain to invalidate its warranty and any AppleCare+ cover. That could change in the future, at least for some models like the Mac mini and Studio, but I think it unlikely that Apple would ever make an upgrade cheaper than initial purchase.
External boot disk
One of the few compelling reasons for choosing a Mac with minimal internal storage is when it’s going to be started up from an external boot disk. Because Apple silicon Macs must always start their boot process from their internal storage, and that Mac still needs Recovery and other features on its internal SSD, you can’t run entirely from an external SSD, but you could probably get away with the smallest available for its other specifications, either 256 or 512 GB.
Apple silicon Macs are designed to start up and run from their internal storage. Unlike Intel Macs with T2 chips, they will still boot from an external disk with Full Security, but there are several disadvantages in them doing so. Among those are the fact that, on an external boot disk, FileVault encryption isn’t performed in hardware and is inherently less secure, and AI isn’t currently supported when booted from an external disk. Choosing to do that thus involves compromises that you might not want to be stuck with throughout the lifetime of that Mac.
External media libraries
Regardless of the capacity of a Mac’s internal storage, it’s popular to store large media libraries on external storage, and for many that’s essential. This needs to be planned carefully: some libraries are easier to relocate than others, and provision has to be made for their backups. If you use hourly Time Machine backups for your working folders, you’ll probably want to back up external media libraries less frequently, and to different external storage.
External Home folder
Although it remains possible to relocate a user’s entire Home folder to external storage, this seems to have become more tricky in recent versions of macOS. Home folders also contain some of the most active files, particularly those in ~/Library, so moving them to an external SSD is going to require its good performance.
A more flexible alternative is to extend some working folders to external storage, while retaining the Home folder on internal storage. This can fit well with backup schedules, but you will still need to ensure the whole Home folder is backed up sufficiently frequently. This does have an unfortunate side-effect in privacy protection: this may require most of your working apps to be given access to Removable Volumes in the Files & Folders item in Privacy & Security settings. Thankfully, that should only need to be performed once when first using an app with external storage.
How much free space do you need?
When you’re weighing up your options to minimise the size of your new Mac’s internal storage, you also need to allow sufficient free space on each disk. APFS is very different from HFS+ in this respect: on external disks, in particular, HFS+ continues to work happily with just a few MB free, and could be filled almost to capacity. APFS, modern macOS and SSDs don’t work like that.
Measuring how much free space is needed isn’t straightforward either, as macOS trims back on its usage in response to falling free space. Some key features, such as retaining log entries, are sacrificed to allow others to continue. Snapshots can be removed or not made. Perhaps the best measurements come from observing the space requirements of VMs, where total virtual disk space much below 50 GB impairs running of normal functions. That’s the total size of the virtual disk, not the amount of free space, and doesn’t apply when iCloud or AI are enabled.
The other indicator of minimum free space requirements is for successful upgrading of macOS, which appears to be somewhere between 30-40 GB. This makes it preferable to keep an absolute minimum of around 50 GB free at all times. When possible, 100 GB gives more room for comfort.
SSD wear and performance
When the first M1 Macs were released, base models with just 8 GB of memory and 128 GB internal SSDs were most readily available, with custom builds (BTO) following later. As a result, many of those who set out to assess Apple’s new Macs ended up stress-testing those with inadequate memory and storage for the tasks they ran.
Many noticed rapid changes in their SSD wear indicators, and some were getting worryingly close to the end of their expected working life after just three years. Users also reported that SSD performance was falling. The reasons for those are that SSDs work best, age slowest, and remain fastest when they have ample free space. One common rule of thumb is to keep at least 20-25% of SSD capacity as free space, although evidence is largely empirical, and in places confused.
The simplest factor to understand is the effect of SSD size on wear. As the memory in an SSD is expected to last a fixed number of erase-write cycles, all other things being equal, writing and rewriting the same amount of data to a smaller SSD will reach that number more quickly. Thus, in general terms and under the same write load, a 512 GB SSD will last about half as long as a 1 TB SSD.
All other things aren’t equal, though, and that’s where wear levelling and Trim come into play. Without levelling the number of erase-write cycles across all the memory in an SSD, some would reach their limit far sooner than others. To tackle that, SSDs incorporate mechanisms to even out the use of individual memory cells, as wear levelling. The less free space available on an SSD, the less effective wear levelling can be, giving larger SSDs a significant advantage if they also have more free space.
Trimming is performed periodically to allow storage that has already been made available for reuse, for example when a file has been deleted, to be erased and made ready. Both APFS and HFS+ will Trim compatible SSDs when mounting a volume, but Trim support for external SSDs is only provided by default for those with NVMe interfaces, not SATA, and isn’t available for other file systems including ExFAT. Some SSDs may still be able to process available storage in their routine housekeeping, but others won’t. Without Trimming, an SSD gradually fills with unused memory waiting to be erased, and will steadily grind to a halt, with write speeds falling to about 10% of new.
Thus, to ensure optimum performance and working life, SSDs should be as large as possible, with much of their storage kept free. Experience suggests that a healthy amount of free space is 20-50% of their capacity.
Striking the best compromise
Apple silicon Macs work best and fastest when largely running from their internal SSDs. By all means reduce the capacity required by moving more static media libraries, and possibly large working folders, to an external SSD. But there’s no escaping the evidence that your Mac will work best and longest when its internal storage has a minimum of 20% free at all times, and you must ensure that never falls below 50 GB free space. Finally, consider your needs not today, but when you intend replacing that Mac in 3-5 years time, or any savings made now will prove a false economy.
Making a CPU do more work requires more than increasing its frequency, it needs removal of obstacles that can prevent it from making best use of those cycles. Among the most important of those is memory access. High-speed local caches, L1 and L2, can be a great help, but in the worst case fetching data from memory can still take hundreds of CPU core cycles, and that memory latency may then delay a running process. This article explains some techniques that are used in the CPU cores of Apple silicon chips, to improve processing speed by making execution more efficient and less likely to be delayed.
Out-of-order execution
No matter how well a compiler and build system might try to optimise the instructions they assemble into executable code, when it comes to running that code there are ways to improve its efficiency. Modern CPU cores use a pipeline architecture for processing instructions, and can reorder them to maintain optimum instruction throughput. This uses a re-order buffer (ROB), which can be large to allow for greatest optimisation. All Apple silicon CPU cores, from the M1 onwards, use out-of-order execution with ROBs, and more recent families appear to have undergone further improvement.
In addition to executing instructions out of order, many modern processors perform speculative execution. For example, when code is running a loop to perform repeated series of operations, the core will speculate that it will keep running that loop, so rather than wait to work out whether it should loop again, it presses on. If it then turns out that it had reached the end of the loop phase, the core rolls back to where it entered the loop and follows the correct branch.
Although this wastes a little time on the last run of each loop, if it’s had to loop a million times before that, accumulated time savings can be considerable. However, on its own speculative execution can be limited by data that has to be loaded from memory in each loop, so more recently CPU cores have tried to speculate on the data they require.
Load address prediction
One common pattern of data access within code loops is in their addresses in memory. This occurs when the loop is working through a stored array of data, where the address of each item is at a constant address increment. For this, the core watches the series of addresses being accessed, and once it detects that they follow a regular pattern, it performs Load Address Prediction (LAP) to guess the next address to be used.
The core then performs two functions simultaneously: it proceeds to execute the loop using the guessed address, while continuing to load the actual address. Once it can, it then compares the predicted and actual addresses. If it guessed correctly, it continues execution; if it guessed wrong, then it rolls back in the code, uses the actual address, and resumes execution with that instead.
As with speculative execution, this pays off when there are a million addresses in a strict pattern, but loses out when a pattern breaks.
Load value prediction
LAP only handles addresses in memory, whose contents may differ. In other cases, values fetched from memory can be identical. To take advantage of that, the core can watch the value being loaded each time the code passes through the loop. This might represent a constant being used in a calculation, for example.
When the core sees that the same value is being used each time, it performs Load Value Prediction (LVP) to guess the next value to be loaded. This works essentially the same as LAP, with comparison between the predicted and actual values used to determine whether to proceed or to roll back and use the correct value.
This diagram summarises the three types of speculative execution now used in Apple silicon CPU cores, and identifies which families in the M-series use each.
Vulnerabilities
Speculative execution was first discovered to be vulnerable in 2017, and this was made public seven years ago, in early 2018, in a class of attack techniques known as Spectre. LAP and LVP were demonstrated and exploited in SLAP and FLOP in 2024-25.
Mechanisms for exploiting speculative designs are complex, and rely on a combination of training and misprediction to give an attacker access to the memory of other processes. The only robust protection is to disable speculation altogether, although various types of mitigation have also been developed for Spectre. The impact of disabling speculative execution, LAP or LVP greatly impairs performance in many situations, and isn’t generally considered commercially feasible.
Risks
The existence of vulnerabilities that can be exploited might appear worrying, particularly as their demonstrations use JavaScript running in crafted websites. But translating those into a significant risk is more challenging, and a task for Apple and those who develop browsers to run in macOS. It’s also a challenge to third-parties who develop security software, as detecting attempts to exploit vulnerabilities in speculative behaviour is relatively novel.
One reason we haven’t seen many (if any) attacks using the Spectre family of vulnerabilities is that they’re hardware specific. For an attacker to use them successfully on a worthwhile proportion of computers, they would need to detect the CPU and run code developed specifically for that. SLAP and FLOP are similar, in that neither would succeed on Intel or M1 Macs, and FLOP requires the LVP support of an M3 or M4. They’re also reliant on locating valuable secrets in memory. If you never open potentially malicious web pages when your browser already has exploitable pages loaded, then they’re unlikely to be able to take advantage of the opportunity.
Where these vulnerabilities are more likely to be exploited is in more sophisticated, targeted attacks that succeed most when undetected for long periods, those more typical of surveillance by affiliates of nation-states.
In the longer term, as more advanced CPU cores become commonplace, risks inherent in speculative execution can only grow, unless Apple and other core designers address these vulnerabilities effectively. What today is impressive leading-edge security research will help change tomorrow’s processor designs.
Unlike Intel Macs (including those with T2 chips), all Apple silicon Macs always start their boot process from their internal SSD, even when they are set to start up from a bootable external disk. This ensures the security and integrity of that process and prevents an attacker from starting that Mac up without credentials. This article explains how this affects the use of Apple silicon Macs.
Bootable external disks
In addition to normal requirements for a macOS installation on an external disk to be able to boot a Mac, ownership of the boot volume group on that disk is required. This is normally performed when installing macOS on that disk, as explained here, and results in the ownership of that boot volume group by an authorised user of that Mac. This is incorporated into a LocalPolicy that is saved to the internal SSD of that Mac.
If that ownership and LocalPolicy haven’t been created at the time of installation, macOS should prompt for their creation when you select that external disk as a startup disk, in System Settings or Recovery mode. That enables an existing external disk to be made bootable for another Mac. If that fails, then macOS will refuse to start up from that external disk.
Disk structure
To accommodate the more advanced Secure Boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.
The boot volume group itself is composed of:
The System volume, used to build the SSV, which is unmounted during normal running.
The Signed System Volume, SSV, a signed and sealed snapshot of the System volume, containing the immutable System.
The Data volume, by default named Data, mounted within the System directory tree, and writable by the user.
The small Preboot volume, used to store cryptexes.
The paired Recovery volume, containing a disk image of the Recovery system.
The VM volume as the backing store for virtual memory.
Possibly an Update volume that appears to have been used when upgrading to versions of Big Sur. This won’t be present on more recent Macs, and appears to have been disused since macOS 11.
The SSV is created from the System volume during macOS installation and update, and features a tree of cryptographic hashes verifying its integrity, and its signature to verify that its contents match those expected for that version of macOS.
Boot process
On Apple silicon Macs, this starts with the Boot ROM to validate the Low Level Bootloader (LLB), stage 1 of the boot process. The LLB in turn validates other firmware to be used in Stage 2, the LocalPolicy to be applied to the startup disk, and iBoot (Stage 2) itself, in accordance with the requirements of the applicable LocalPolicy. When starting up from a boot volume on an external disk, control is then transferred to that bootable system, which is stored in a single APFS container with the same layout as that for an Intel Mac.
Thus, when starting up from an external disk, M-series Macs require LLB and iBoot together with LocalPolicy all stored on the internal SSD. As LLB and iBoot are part of a macOS install, the best way to provide those is in a full installation of the current release of macOS.
LocalPolicy
The user controls LocalPolicy through Startup Security Utility, which is only accessible in Recovery Mode, and requires user authentication. There’s no LocalPolicy that applies to all users and all disks, though: each LocalPolicy is specific to a boot volume group and authorised user. For example, these can allow:
a single bootable external disk to be used to start up two or more Macs;
one Mac to be started up from any of several boot volume groups, which can be running older versions of macOS, or could load third-party kernel extensions.
Default LocalPolicy created for each bootable external disk provides Full Security, which among other things blocks the loading of third-party kernel extensions and requires SIP to be fully enabled. iBoot (Stage 2) validates kernel collections, signed System volumes, and other components to ensure their integrity, and that the kernel, extensions and macOS to be loaded have an acceptable version number.
LocalPolicy can be changed, in particular by changing Secure Boot settings using Startup Security Utility, first booting from that boot volume group, shutting down, and starting up in Recovery mode. That sequence ensures that the Mac boots into the Recovery volume paired with the System volume whose security settings are to be changed.
Fallback
The current startup disk setting is stored in NVRAM, which on Apple silicon Macs can’t readily be reset by the user. In the event that disk can’t be used to boot that Mac, it will normally fall back to starting up from the internal SSD. This is a more convoluted process in the event that the expected startup disk can’t be found at all: in that case, there may be a long delay in startup, during which the power light will remain on but the display remains black. Eventually, when all hope of finding the missing boot disk is abandoned, the Mac may boot from the hidden Recovery container on the internal SSD, normally used as Fallback Recovery, enabling the user to choose another startup disk and restart from that.
External boot volume groups
The boot volume group on external storage has the same structure and features as that in the Apple_APFS container of the internal SSD, and once it has started up is self-sufficient. macOS is contained in its SSV, with cryptexes saved to its Preboot volume. Writeable system data, and all user data, are saved to its Data volume, and it has its own paired Recovery volume, used when the external system is booted into Recovery mode.
Its macOS is updated independently of that installed on the internal SSD, although any firmware updates to be installed as part of a macOS update change the firmware on the internal SSD, as there’s no firmware on the external SSD. In the event that internal and external macOS versions differ, the installer or updater will only ever update the firmware to the more recent version.
DFU mode
Apple silicon Macs are the first Apple computers whose firmware can be both upgraded and downgraded by installation of an IPSW image file when the Mac is in DFU mode. This enables you to erase the whole of the internal SSD and install all three containers, with firmware, the SSV and Data volumes to factory-fresh condition, for any supported version of macOS. This is invaluable when there’s a problem with firmware, corruption of the internal SSD without physical damage, or simply to revert to an older macOS.
Because restoring in DFU mode erases the whole of the internal SSD, it also blows away all saved LocalPolicy for that Mac. Following the restore process, any bootable external disk used with that Mac will need to have its ownership re-established so that a new LocalPolicy can be created for it.
Key points
To be bootable from an Apple silicon Mac, an external disk needs ownership of its boot volume group, and LocalPolicy for it.
Ownership is normally assigned and LocalPolicy created during macOS installation.
Ownership and LocalPolicy can also be created when selecting an external disk as the startup disk. That allows an external disk to be bootable with more than one Apple silicon Mac.
A complete macOS boot volume group is still required on the internal SSD to be able to boot from external disks, as the early stages of the boot process, including validation of its LocalPolicy, can only be run from the internal SSD.
LocalPolicy can be changed using Startup Security Utility in the paired Recovery volume.
Fallback policy ensures that a Mac can still start up if the expected external boot disk fails to boot, or is missing.
External boot volume groups are self-sufficient and don’t rely on the internal SSD once they have booted successfully.
All stored LocalPolicy is destroyed when a Mac is restored in DFU mode, and ownership and LocalPolicy then have to be recreated for any external bootable disks.
Whether you’ve become familiar with the basics in Recovery mode on Apple silicon Macs, or you just need deeper information, this article is intended to supplement my illustrated guide.
Which Recovery mode?
Unless your Mac has two or more systems installed, there are only two Recovery modes:
Paired Recovery, the default, run from a mounted disk image stored in the Recovery volume in the active boot volume group;
Fallback Recovery, engaged using a short press, then a held press of the Power button, in a ‘di-dah’ rhythm. This isn’t always available, but when it is it runs from a dedicated partition/container on the internal SSD. Although it can do everything else, you can’t use its Startup Security Utility, which is only available in paired Recovery.
This is a bit more complicated when your Mac has more than one bootable system available. The rule then is that it will enter paired Recovery for the current boot volume group. If you have Sonoma and Sequoia installed and want to do anything with the Sonoma boot volume group, then you should make Sonoma the active Startup Disk, and ideally restart into that, before shutting down to start up in Recovery mode. Although the initial Options screen allows you to choose boot volume groups, that procedure ensures that you’ll always use the correct tools for the job.
Change keyboard
Throughout Recovery mode, you can change the default keyboard, which is set to that in NVRAM. At the top right, the keyboard menu offers those standard in macOS. If you’re experiencing problems entering your password, check that you’re using the right keyboard here.
Installer Log
This is useful for the checks that it reports, including statements that the network is reachable, and details of the current user, whether they have admin privileges, and have a secure token to be able to unlock FileVault. If you need to get into the weeds, its popup menu can be set to Show All Logs, and you might even be able to save the log to somewhere that’s accessible when back in normal user mode.
Utilities: Share Disk…
This menu command is used to put that Mac into the modern equivalent of Target Disk mode. That requires it to be connected to another Mac using a Thunderbolt or USB data cable, and will then mount its Data volume on that Mac, connected using SMB over the cable. Although not as fast as a direct Thunderbolt connection, it’s valuable if you need to retrieve files from a Mac that can’t boot in normal user mode.
Utilities: Terminal
This opens a bash shell rather than the zsh we’re now used to, as root user. There are a great many useful tools included in the Recovery System, including: fsck, fsck_apfs, mount, mount_apfs, csrutil, asr, nvram, spctl, sysctl, and /usr/bin and /usr/sbin contain many more. The biggest snag with them is that, in 15.3.1 at least, there’s no man command, although many will show their standard usage information with an -h option.
One command tool peculiar to Recovery mode is its equivalent to sysdiagnose, recoverydiagnose, in case you need to file a bug report about Recovery mode.
There’s also repairHomePermissions, which launches a GUI app to repair permissions on a selected Home folder on the Data volume. I strongly recommend that you don’t try using this, as you’ll end up with the user being locked out of every folder in their Home folder. This appears to be a historical remnant that has somehow been left behind, long after it outlived its usefulness.
Utilities: Startup Security Utility
I have already explained at length how to use this to change boot security, in conjunction with adjusting SIP, and more, in this article.
Main Window: Disk Utility
Although Disk Utility invariably opens with its default settings, the version supplied in Recovery is every bit as capable as that in normal user mode. Once it has opened, set its View tool to Show All Devices, and if you want to work with snapshots, set its View menu to Show APFS Snapshots.
Main Window: Safari
As with Disk Utility, the version of Safari provided is almost as fully equipped as normal, and apparently runs from a cryptex. It opens with a local page that explains features in Recovery mode, but you can access Google search engine and pretty well anything else you want, including articles in this blog.
Apple has gone to great lengths to make the transition to its new Arm-based Macs as seamless as possible. However, there are some major differences that most need to take into account before making their leap of faith from a cherished but now-ageing Intel Mac to a sleek and glitzy new M-series Mac. This article clarifies what are often points of confusion about what you can’t or shouldn’t do with a new Apple silicon Mac.
You can’t run any macOS before Monterey (or possibly Big Sur)
There are two ways to run macOS on Apple silicon Macs: natively, or in a virtual machine (VM). The oldest version of macOS your Mac can run natively is that current at the time that model was released. Models released before October 2021 can run macOS 11 Big Sur, and are the only Apple silicon Macs that can do so. Those released from October 2021 onwards can only run the version of macOS that was current at the time of their release, but can run older versions back to macOS 12 Monterey in a VM. Current models with M4 chips are even more restricted, as the earliest version they can run is macOS 15 Sequoia, although their VMs can still stretch back to Monterey if you need.
Catalina, Mojave and earlier were never released with support for Apple silicon Macs, so can’t be run on them, and will never be able to without emulating Intel processors in software, which is slow and unreliable.
A VM running on an Apple silicon Mac can’t run Big Sur, because the Virtio driver support required for virtualisation wasn’t complete then, and didn’t work until macOS 12 Monterey, although even there it offers fewer features than in Ventura. Full details are given here.
You can’t virtualise or run Intel macOS or 32-bit apps
Bundled in macOS is Rosetta 2, enabling you to run 64-bit Intel code and apps that are compatible with macOS 10.15 Catalina. Rosetta isn’t an emulation engine, but translates code from Intel to Arm instructions. However, it can’t translate 32-bit code, and it can’t translate operating systems like macOS. It does run 64-bit Intel apps amazingly quickly, though.
A VM running macOS on Apple silicon can therefore use Rosetta 2 to translate and run 64-bit Intel code in apps that are compatible with macOS 10.15 Catalina, but is subject to the same limitations as any version of macOS on Apple silicon, in that it can’t handle older or 32-bit apps. Neither can it be used on the host Mac to run a VM of any Intel version of macOS.
If you need access to older or 32-bit Intel software, then the only practical way of doing that is on an Intel Mac that’s able to run Mojave or earlier.
You can’t install Intel kernel extensions
Rosetta 2 translation can’t support the privileged level of execution required for kernel extensions, so if you need your Mac to be able to load and use kernel extensions that are only available for Intel Macs, you can’t do that on an Apple silicon Mac. The great majority of more recent kernel extensions are now available as Universal versions that can also run native on M-series chips, but if your Mac still relies on an older kernel extension that’s Intel-only, then you can’t use that on a new Mac.
You can’t boot fully from an external drive
Unlike Intel Macs, Apple silicon models can only start their boot process from their internal SSD, as that’s required to support their Secure Boot. Although Apple silicon Macs can boot from external disks, early phases of that process still rely on the internal SSD and security policies (‘LocalPolicy’) saved there. This has several consequences:
An Apple silicon Mac can only boot from an external disk that is ‘owned’ by a user recognised by the primary system on its internal SSD. This is a valuable security measure, as without knowing login details for a suitable user of the internal SSD, it’s not possible to boot an Apple silicon Mac from an external bootable disk.
An Apple silicon Mac can only boot from an external disk if it can at least start that process from its internal SSD, normally requiring a bootable system on the internal SSD as well. If you do intend booting your Mac from an external disk, in practice you still need to install and maintain a bootable system on its internal SSD.
Total failure of the internal SSD results in failure to boot from external disks as well. A bootable external disk can’t ‘get you home’ in that emergency.
Apple silicon Macs don’t really boot fully from ‘bootable’ external installer disks, although they can still be used to install macOS when necessary, and may be required when installing older versions of macOS than currently installed.
Instructions for installing macOS on an external disk so that it can boot an Apple silicon Mac are given here.
You can’t use Boot Camp
Boot Camp allows you to start up an Intel Mac as if it’s a regular PC to run Windows. As Apple silicon Macs have completely different processors and other hardware, they can’t support that option. If you want to run Windows on your Apple silicon Mac, you’ll have to do that using a virtualiser like Parallels Desktop, and currently those can only run Arm versions of Windows, although Parallels is working on an emulator that can run some Intel versions. You can already try that out.
Avoid kernel extensions
Unlike Intel Macs, Apple silicon Macs don’t allow the use of third-party kernel extensions when running in Full Security mode. Before it can have those enabled, its startup security has to be reduced, and their use explicitly set in Startup Security Utility in Recovery mode. For most users that’s a significant deterrent. In almost all cases now, traditional kernel extensions should be replaced by new-style system extensions. You can read more about that here.
Avoid ‘cloning’ boot volume groups
Before Catalina and Big Sur divided the boot volume into a group of volumes, including System and Data, it was popular to make identical copies of, or ‘clone’, the volume containing the system. This is even more complex with Apple silicon Macs because of the multiple containers on their internal SSD. Although apps like SuperDuper and Carbon Copy Cloner can still create clones, they can’t include the whole of the internal SSD. That limits their usefulness, and they can readily fail.
The only way you can completely replace the contents of the internal SSD of an Apple silicon Mac is to restore it from an IPSW image file when the Mac is in DFU mode. That erases the SSD so that its Data volume then has to be restored from a backup or copy, not a task to be undertaken lightly or in a hurry. This is explored in detail here.
Don’t try using startup key combinations
Entering Recovery mode and accessing features that are controlled using startup key combinations on Intel Macs is completely different in Apple silicon Macs, and controlled using the Power button. Holding keys during startup does nothing for an Apple silicon Mac. I have an illustrated guide, details on Fallback Recovery, and on troubleshooting.
Neither can you reset the PMC or NVRAM using startup keys. The PMC in an Apple silicon Mac is completely different, and shouldn’t need to be reset. If it does, then restarting should suffice. NVRAM is primarily for the use of macOS not the user, and you should never have to reset it. Further information is given here.
Further reading
My page listing articles specific to Apple silicon Macs contains extensive information and guidance.
Good news: almost exactly three years after I reported that you couldn’t control what an Apple silicon MacBook Pro or Air does when you open its lid, Apple has addressed this.
Intel models
Since about 2016, Intel MacBook Air and Pro models may have an ‘auto boot’ feature, and either start up or wake from sleep when you open their lid. This behaviour is controlled by the AutoBoot setting in their NVRAM. If you want to disable auto boot startup, then open Terminal, type in the command sudo nvram AutoBoot=%00
and authenticate with your admin password. When you next open the lid, that Mac won’t start up until you tell it to.
To disable that, and restore auto boot, enter the Terminal command sudo nvram AutoBoot=%03
and authenticate again. It will also be restored if you reset NVRAM.
Apple silicon models
The procedure for Intel Macs doesn’t work in Apple silicon models, and the NVRAM setting that looked as if it might work, auto-boot, mustn’t be used as it can cause boot problems. Leave it well alone unless you fancy performing a full restore in DFU mode.
According to Apple’s recent support note, it’s now possible to change auto boot behaviour in MacBook Air and Pro models with Apple silicon chips using the BootPreference setting, when they’re running macOS Sequoia.
To disable auto boot when opening the lid or connecting to power, enter the Terminal command sudo nvram BootPreference=%00
To disable auto boot when opening the lid, but for it still to work when connecting to power, enter the Terminal command sudo nvram BootPreference=%01
To disable auto boot when connecting to power, but for it still to work when opening the lid, enter the Terminal command sudo nvram BootPreference=%02
To restore normal auto boot behaviour, enter the Terminal command sudo nvram -d BootPreference
to delete that setting in the NVRAM.
You can also list the contents of NVRAM with the command nvram -p
which is helpful when you’re not sure what the setting is, or whether it has been removed from NVRAM altogether to return that Mac to its default behaviour.
Be particularly careful when making any changes to the NVRAM in an Apple silicon Mac: if you make a mistake there’s no easy way to reset the NVRAM, and your Mac could be taking a trip to DFU mode before it will work properly again.
Cleaning keys or trackpad
Auto boot only determines start up behaviour on opening the lid or connecting power. When the lid is open, pressing any key or using the touchpad will still cause the Mac to start up, so limiting use for cleaning its keys or touchpad. Apple recommends using compressed air, which shouldn’t start the Mac up, but if you prefer to use a dry cloth or isopropyl alcohol on a cloth (but never a water-based cleaner), then you may find it helpful to use KeyboardCleanTool to block key entry during cleaning.
Whatever you do, don’t let any water=based liquid near your Mac’s keyboard or other areas that could allow its ingress. Even small amounts of water can cause serious damage that can require expensive repairs. Like all laptops, MacBook Air and Pro models contain multiple water sensors, making that damage easy to detect. Water damage is included in AppleCare+, but will still cost you $299, and may not be covered by other insurance policies.
I’d love to be able to bring you a Mac magic trick every Friday, but they aren’t so easy to discover. Today’s is mainly for those with Apple silicon Macs, and is all about gaming the way that macOS allocates threads to their cores. Here, I’ll show you how to more than double the performance of the E cores at no cost to the P cores.
To do this, I’m using my test app AsmAttic to run two different types of core-intensive threads, one performing floating point maths including a fused multiply-add operation, the other running the NEON vector processor flat out.
When I run a single NEON thread of a billion loops at low Quality of Service (QoS) so that it’s run on the E cores, it takes 2.61 seconds to complete, instead of the 0.60 seconds it takes on a P core. But how can I get that same thread, running on the E cluster, to complete in only 1.03 seconds, 40% of the time it should take, and closer to the performance of a P core?
The answer is to run 11 more threads of 3 billion loops of floating point at the same time. That might seem paradoxical, particularly when those additional threads perform the same with or without that NEON thread on the E cores, so come for free. Perhaps I’d better explain what’s going on here.
Normally, when you run these threads at low QoS, macOS runs them on the E cores, at low frequency for added efficiency. On the M4 Pro used for these tests, the NEON test that took 2.61 seconds was on E cores pottering along at a frequency of less than 1,100 MHz across the whole of the E cluster, not much faster than their idle frequency of 1,020 MHz.
One way to get macOS to increase the frequency of all the E cores in the cluster is to persuade it to run a thread with high QoS that won’t fit onto the P cores. In this M4 Pro, that means loading its CPU with 11 floating point threads, of which 10 will be run on the two clusters of 5 P cores each. That leaves the eleventh thread to go on the E cluster. macOS then kindly increases the frequency of the E cluster to around 2,592 MHz, giving my NEON thread a speed boost of around 235%, which accounts for the performance increase I observed.
These two tests are shown in the CPU History window from Activity Monitor. The single NEON thread run alone in the E cluster is marked by 1, when there was essentially no activity in the P cores. The figure 2 marks when the same NEON thread was run while all 10 P cores and one of the E cores were running the floating point maths. Yet the NEON thread at 2 completed in less than half the time of that at 1.
With just two substantial threads running on the E cluster, there’s just as much processing power as when there was just the one floating point thread. So the 11 floating point threads complete in the same time, regardless of whether the NEON thread is also running. Therefore this extra performance comes free, with nothing else being slowed to compensate.
Of course in the real world, this sort of effect is likely to be extremely rare. But it might account for the occasional unexpectedly good performance of a background thread running at low QoS, and I can’t see any downsides either.
The other way you could get that low QoS thread to perform far better would be running it in a Virtual Machine, as that runs everything on P cores regardless of their QoS. Sadly, despite searching extensively, I still haven’t discovered any other way of convincing macOS to run low QoS threads any faster, except by magic.
As the first batches of Thunderbolt 5 SSDs are starting to ship, this is a good time to take stock of what we have seen so far. Here I include some current results obtained from testing one of these new products.
So far, products that have already been released or are well into pre-order include:
OWC Envoy Ultra,
LaCie Rugged SSD Pro 5,
Sabrent Rocket XTRM5.
Starting prices for these are under $/€/£ 400 for 2 TB, making them a little more expensive than better USB4 or Thunderbolt 3 equivalents. I am very grateful to Jozef for telling me that Acasis are promising to ship a TB5-compatible empty enclosure imminently, although at $300 it doesn’t make self-assembly attractive yet. If you’re interested, he has included a link to the product page in his comment below.
Mac support
The only Macs that currently support TB5 are the latest MacBook Pro and Mac minis equipped with M4 Pro or Max chips. Although they’re claimed to support full-speed TB5 performance when running macOS Sequoia 15.0, problems have been reported in achieving that, at least with TB5 docks and hubs. If you intend using any TB5 peripheral, then you’d best start with 15.3, which has been reported as solving at least some of those problems. This may also explain some of the anomalies in SSD performance that have been claimed by a few early testers.
Other Apple silicon Macs should run TB5 SSDs in USB4 40 Gb/s mode, which should still be significantly faster than TB3. Intel Macs don’t support TB5 or USB4, though, so they’re most likely to fall back to run them as USB 3.2 Gen 2, at 1 GB/s, which would be a deep disappointment for the cost.
Benchmarks
Beware of claimed performance of TB5 SSDs by their manufacturers and in product reviews. Testing them isn’t as straightforward as with slower products.
For a start, quoted results are often taken from apps such as Blackmagic Disk Speed Test and AmorphousDiskMark. Although both have their uses, they also have their limits, notably that they only measure read and write speed for one test size, normally 5 GB in the former and 1 GiB in the latter. As the graph below shows, there are substantial differences in speed between different sizes.
The upper pair of unbroken lines show read and write speeds when operating in TB5 mode over 80 Gb/s to the Mac mini M4 Pro, and the pair below them with broken lines shows speeds when operating in USB4 mode over 40 Gb/s to a MacBook Pro M3 Pro. Calculated overall read/write speeds were 5.2/5.5 GB/s for TB5, and 3.1/3.1 GB/s for USB4. For comparison, Blackmagic returned 4.8/5.2 GB/s, and Amorphous 6.8/5.3 GB/s. Needless to say, the latter is the result being quoted by the manufacturer, despite its write speed looking highly suspect.
Highest read and write speeds were measured with 400 MB size, and there were only small differences once sizes exceeded 600 MB. However, speeds for files below 10 MB were considerably less than 100 MB and larger. Fortunately, Blackmagic Disk Speed Test and AmorphousDiskMark both use sizes in the more linear range above 600 MB, but their results don’t take into account smaller file sizes, which are more common in many real-world circumstances. As the 80th centile write speed was 5.62 GB/s, the write speed reported by Amorphous of 6.8 GB/s doesn’t appear representative.
Caching effects
All those benchmark results are subject to a major caution: they don’t provide any information on caching, used by most faster SSDs to improve performance. This typically uses part of the memory in SLC mode, sacrificing capacity for speed. I’ve seen a figure of 50 GB of cache quoted for one TB5 SSD that I’ve tested, and sure enough, once 50 GB has been written to it, its write speed drops from around 5.5 to 1.4 GB/s.
Few are likely to write more than 50 GB to an SSD in a single continuous session, but for those that do, it’s important to know when the SLC cache is likely to become full, and for write speed to fall to little better than USB 3.2 Gen 2. Neither Blackmagic Disk Speed Test nor AmorphousDiskMark can measure that for you.
Overall impressions
Thunderbolt 5 SSDs are starting to realise their promise of significantly faster read and write performance than even USB4 SSDs. Although TB5 SSDs are supported by a small range of the latest Macs, they should still be faster than TB3 when they fall back to USB4 on other Apple silicon Macs. However, if they’re to be used with Intel Macs, the likelihood is that they will fall further back to USB 3.2 Gen 2.
If you’re likely to stream very large quantities of data to them, more than about 50 GB, then you’ll need to obtain an estimate of the size of their SLC cache, and of their write performance when that is full, or you could be in for a big disappointment. The trouble with TB5 SSDs is that they’re sufficiently fast to fill their cache very quickly, in this case in around 10 seconds when writing at full speed.
Postscript
I’ve gone back to my original article analysing TB5 performance, and the maximum transfer rate it can achieve over its 80 Gb/s works out at 6 GB/s. I therefore conclude that the claimed 6.7 GB/s reported above can only be bogus, although it’s now being claimed by manufacturers and other testing sites. If you see TB5 claimed to exceed 6 GB/s, then don’t trust those figures.
When you’ve decided that the only way to do what you need is inside a virtual machine (VM), working out how to accomplish that might appear challenging. Because all macOS virtualisers on Apple silicon Macs use features built into macOS, they’re also similar in use. This article explains how to get started.
VMs for macOS on Apple silicon Macs consist of a bundle folder, containing key files often named:
Disk.img or [name].hdd, the bootable virtual disk image, typically about 7 GB larger than the space allocated to the boot disk, stored in sparse file format, so taking far less space on the host’s storage;
MachineIdentifier or macid.bin, 68 bytes or so containing the unique ID for the VM;
HardwareModel or machw.bin, around 150 bytes;
AuxiliaryStorage or aux.bin, around 33 MB containing private data.
Some virtualisers also store a property list or other files such as config.pvs and VmInfo.pvi containing settings for the VM.
Location
Even a small, basic VM requires more than 40 GB of storage space. If it’s kept in a location that’s backed up by Time Machine or a third-party equivalent, it may quickly fill those backups. At the very least, a folder containing VMs should be excluded from normal backups, and perhaps copied to separate storage once a day.
VMs will also be included in any snapshots made of that volume. To avoid that penalty, they should be stored in their own volume that doesn’t have snapshots made of it, as well as being excluded from normal backups.
Download IPSW file
VMs are built from the complete image of an Apple silicon Mac boot disk provided in an IPSW file, currently around 16.5 GB but significantly smaller in older versions. Those should only be downloaded from Apple’s servers. Several sites provide links to those, including Mr. Macintosh, who also includes most beta-releases.
Most virtualisers also give direct access to the current release of macOS in its IPSW file, as that’s a feature provided by the API.
Create a VM
In this phase, the VM bundle folder is created with a unique MachineIdentifier, and the contents of the IPSW file are installed into the disk image. The latter is usually fastest from a file in the same volume, and some virtualisers follow Apple’s example of moving the IPSW inside the bundle to perform that, rather than copying it there and deleting that copy once the VM has been created.
The only control for this stage is to set the size of the disk image in Disk.img. As that’s stored as a sparse file, it’s wise not to skimp and end up with a VM that can’t update itself, for example. For recent macOS, a prudent minimum is 50 GB, and 100 GB gives ample room for the VM to contain additional apps, and for a functional Home folder.
At the end of this phase, the new VM is bootable, and ready for its first run, during which macOS will be personalised and the VM configured. Some virtualisers proceed directly to that first run, in which case their initial settings for it will then be used to run macOS.
First run
This follows the same sequence as the first run on a brand new Mac that has just been unboxed, starting with language and keyboard localisation, passing through migration and Apple Account, and ending in the running VM.
Migration during initial setup isn’t possible, as the VM has no access to any host storage, and if run later faces similar challenges. Although you may enable Location Services, VMs appear unable to use them, possibly because of their inability to use Wi-Fi settings. One of the first checks to perform in a new VM is to switch Time Zone selection to manual and set the correct zone.
Apple Account and iCloud access only work in Sequoia guests running on Sequoia hosts, and will fail for all other combinations.
As with other runs of a VM, you get to choose how many virtual CPU cores it will use, how much memory it will be allocated, display, network and other settings. Those aren’t built into the VM in the way that its size is, although some virtualisers let you save a VM’s settings as its default.
Traditionally, like Macs, VMs have been quitted by shutting them down, but most virtualisers also let you close a VM in a suspended state.
Virtual resources
All virtualisers should offer you a free choice of the number of virtual CPU cores, memory, network connections, and possibly display options. GPU access can’t be controlled directly, though.
Although it’s possible to run a VM in just a single CPU core, that’s slow and incapable of anything useful. In practice a minimum of 3 is wise, and using substantial apps is better with 4-6. Those must be balanced against the need for cores by the host. Similar considerations apply to memory, where 8 GB is barely sufficient, and 16 GB preferable.
Virtualisers should offer bridged networking, giving the VM its own IP address rather than sharing the host’s using NAT.
Enhanced features
VMs running older versions of macOS have more limited features. One simple way to enrich a VM is to run it through Screen Sharing, either locally on the same Mac, or if you prefer over a local network. This can add features such as:
Drag and drop files between Finder windows in the VM and those on the host, to copy them.
Full support for ISO keyboard layouts, including the key at the left of the numbers row..
A shared clipboard for copy and paste between the VM and the host.
Standard key shortcuts to make screenshots of windows or the virtual display.
Trackpad controls including gestures and smooth action with all guests.
The only time that you should never use this is when you’re going to update macOS in the VM. That will disconnect Screen Sharing and could lead to problems during or after the update.
One-off runs
One of the common purposes of VMs is to run quick tests whose effects you don’t want to be permanent. One method of doing this is to maintain a collection of VMs with different versions of macOS installed. When you want to test one out, duplicate that VM in the Finder (Command-D), run the copy, then when you’ve finished with it, delete it. Because duplicating the VM in the same volume results in file cloning, this is almost instant, and uses relatively little real storage space, while preserving the original.
This is also a useful technique when you want to test a potentially destructive process, as you can make as many duplicates of the original as you want. The only caution is that duplicated VMs have identical MachineIdentifiers, and you should never try running two VMs with the same MachineIdentifier at the same time.
Isolating VMs
One excellent reason for using a VM is to study potentially malicious software, and defences against it. It’s relatively easy to lock a VM down and ensure it’s completely isolated from the host, except in the limited data exchanged between its Virtio drivers.
To prepare a VM for use in isolation, start with a regular VM built using the version of macOS to be used in tests. Duplicate that, and running it with shared folders, load it up with any software to be used during the tests. Shut the VM down, and open it in Recovery mode to change its security, disable SIP and customise it in any other way you require, then shut it down again.
Open that VM using ViableS, deciding then whether you want it to have a network connection. That VM is then running in a sandbox, with no shared folders, and as isolated from the host as possible.
Settings and Vimy
Once you have set a VM up, you may want to run it using the same settings and with a minimum of fuss. My free Vimy runs VMs configured using Viable from a double-click, with a minimum of overhead; Vimy itself uses less than 50 MB of memory. That uses a property list containing settings such as the number of virtual CPU cores and memory, saved inside the VM bundle folder.
Most testing and benchmarks avoid putting heavy loads on CPU and GPU at the same time, so running an Apple silicon chip ‘full on’. This article explores what happens in the CPU and GPU of an M4 Pro when they’re drawing a total of over 50 W, and how that changes in Low Power mode. It concludes my investigations of power modes, for the time being.
Methods
Three test runs were performed on a Mac mini M4 Pro with 10 P and 4 E cores, and a 20-core GPU. In each run, Blender Benchmarks were run using Metal, and shortly after the start of the first of those, monster, 3 billion tight loops of NEON code were run on CPU cores at maximum Quality of Service in 10 threads. From previous separate runs, the monster test runs the GPU at its maximum frequency of 1,578 MHz and 100% active residency, to use about 20 W, and that NEON code runs all 10 P cores at high frequency of about 3,852 MHz and 100% active residency to use about 32 W. This combined testing was performed in each of the three power modes: Low Power, Automatic, and High Power.
In addition to recording test performance, powermetrics was run during the start of each NEON test at its shortest sampling period, with both cpu_power and gpu_power samplers active.
Performance
There was no difference in performance between High Power and Automatic settings, which completed both tasks with the same performance as when they were run separately:
NEON time separate 2.12 s, together High Power 2.12 s, Auto 2.12 s
monster performance separate 1215-1220, together High Power 1221, Auto 1220.
As expected, Low Power performance was greatly reduced. NEON time was 4.33 s (49% performance), even slower than running alone at Low Power (2.87 s), and monster performance 795, slightly lower than running alone at Low Power (837).
High Power mode
This first graph shows CPU core cluster frequencies and active residencies for a period of 0.3 seconds when the monster test was already running, and the NEON test was started.
At time 0, the P0 cluster (black) was shut down, and the P1 cluster (red) running with one core at 100% active residency, a second at about 60%, and at about 3,900 MHz. As the ten test threads were loaded onto the two clusters, cluster frequencies were quickly brought to 3,852 MHz, by reducing that of the P1 cluster and rapidly increasing that of the P0 cluster.
By 0.1 seconds, both clusters were at full active residency and running at 3,852 MHz, where they remained until the NEON test threads completed.
Power used by the CPU followed the same pattern, rising rapidly from about 6,000 mW to about 32,000 mW at 0.1 seconds. GPU power varied between 8,600-23,000 mW, resulting in a peak total power of slightly less than 52,000 mW, and a dip to 40,600 mW. Typical sustained power with both CPU and GPU tests running was 50-52 W.
Low Power mode
These results are more complicated, and involve significant use of the E cluster.
This graph shows active residency alone, and this time includes the E cluster, shown in blue, and the GPU, in purple. NEON test threads were initially loaded into the two P clusters, filling them at 0.13 seconds. After that, threads were moved from some of those P cores to run on E cores instead, leaving just two test threads running on each of the P clusters by 0.26 seconds. Over much of that time the GPU had full active residency, but as that fell threads were moved from E cores back to P cores. By the end of this period of 0.5 seconds, 4 of 5 cores in each of the two P clusters were at 100%, and the GPU was also at 100% active residency.
This bar chart shows changing cluster total active residency for the E (red) and two P (blues) clusters by sample. With 10 test threads and significant overhead, the total should have reached at least 1,000%, which was only achieved in sample 4, and from sample 13 onwards.
Those active residencies are shown in the lower section of this graph (with open circles), together with cluster frequencies (filled circles) above them. As the P clusters were being loaded with test threads, both P clusters (black) were brought to a frequency of only 1,800 MHz, compared with 3,852 MHz in the High Power test. The E cluster (blue) was run throughout at its maximum frequency of 2,592 MHz, except for one sample period. GPU frequency (purple) remained below 1,000 MHz throughout, compared with a steady maximum of 1,578 MHz when at High Power.
Power changed throughout this initial period running the NEON test. Initially, CPU power (red) rose to a peak of 6,660 mW, then fell slowly to 3,500 mW before rising again to about 6,000 mW. GPU power rose to peak at just over 7,000 mW, but at one stage fell to only 26 mW. Total power used by the CPU and GPU ranged between 11-13.2 W, apart from a short period when it fell below 5 W. Those are all far lower than the steadier power use in High Power mode.
How macOS limits power
Running these tests in Low Power mode elicited some of the most sophisticated controls I have seen in Apple silicon chips. Compared to being run unfettered in Automatic or High Power mode, macOS used a combination of strategies to keep CPU and GPU total power use below 13.5 W:
P core frequencies were limited to 1,800 MHz, instead of 3,852 MHz.
High QoS threads that would normally have been run on P cores were transferred to E cores, which were then run at their maximum frequency of 2,592 MHz.
Threads continued to be transferred between E and P cores to balance performance against power use.
GPU frequency was limited to below 1,000 MHz.
Despite reducing power use to a total of 25% of High Power mode, effects on performance were far less, attaining about 50% of that at High Power mode.
Residency is the percentage of time a core is in a specific state. Idle residency is thus the percentage of time that core is idle and not processing instructions. Active residency is the percentage of time it isn’t idle, but is actively processing instructions. Down residency is the percentage of time the core is shut down. All these are independent of the core’s frequency or clock speed.
If you want to run an older version of macOS that your Mac doesn’t support, so can’t boot into, then the only option is to run it within your current macOS. You may be able to do that using one of two methods: virtualisation or emulation. Emulation is normally used when the older macOS runs on a different processor, while virtualisation may be available when the processors share the same architecture.
Running Intel macOS
If you want to run a version of macOS for Intel processors, including Catalina and earlier, then your Apple silicon Mac has to run a software emulation of an Intel processor for that to work. Although this is possible using UTM, emulation is slow and not reliable enough to make this feasible for everyday use. It’s impressive but not practical at present. For an Apple silicon Mac, that automatically rules out running any macOS before Big Sur, the first version with support for Arm processors.
Rosetta 2 for Apple silicon Macs isn’t an emulator, although it allows you to run code built for Intel Macs on Apple silicon. It achieves that by translating the instructions in that code to those for the Arm cores in Apple silicon chips. This is highly effective and in most cases runs at near-native speed, but Rosetta 2 can’t be used to translate operating systems like macOS, so can’t help with running older macOS.
Virtualisation
Virtualisation is far more practical than emulation, as it doesn’t involve any translation, and most code in the virtualised operating system should run direct on your Mac’s CPU cores and GPU. What is required for virtualisation to work is driver support to handle access to devices such as storage, networks, keyboards and other input devices. Those enable apps running in macOS inside the virtual machine (VM), the guest, to use features of the host Mac.
Virtualisation of macOS, Windows and Linux have been relatively straightforward in the past on Intel Macs, as they’re essentially PCs, and providing driver support for guest operating systems has been feasible. That has changed fundamentally with Apple silicon chips, where every hardware device has its own driver unique to Apple, and undocumented. Without devoting huge resources to the project, it simply isn’t feasible for third-parties to develop their own virtualisation of macOS on Apple silicon.
Recognising this problem, Apple has adopted a solution that makes it simple to virtualise supported macOS (and Linux) using a system of Virtio drivers. Those have been progressively written into macOS so that it works both as a guest and host, for services that are supported by a Virtio driver, and all versions of macOS since Monterey have been able to virtualise Monterey and later when running on Apple silicon.
The drawback is that, although features supported by Virtio drivers are readily implemented in virtualisers, those that aren’t can’t be supported unless Apple builds a new Virtio driver into macOS. Even then, that new feature will only be available in that and later versions of macOS on both host and guest, as support is needed in both before it can work.
Another important consequence of virtualisation being built into macOS is that different virtualising apps all rely on the same features, and act as wrappers for macOS. While different apps may offer different sets of features and present them in their own interface, virtualisation is identical inside them. I’m not aware of any macOS virtualiser on Apple silicon that doesn’t use the API in macOS, and they all share its common limitations and strengths. This also means that, when there’s a bug in virtualisation within macOS, it affects all virtualisers equally.
macOS support
Early Virtio support appeared first in macOS Mojave and gathered pace through Catalina and Big Sur, but the first version of macOS to support virtualisation of macOS on Apple silicon Macs was Monterey 12.0. That means that no Mac released after the release of Monterey in the autumn/fall of 2021 will ever be able to run Big Sur, as their hardware isn’t supported by it, and macOS 11 can’t be virtualised. The only way to retain access to Big Sur is to keep an M1 Mac that shipped with it, the last of which was the iMac 24-inch M1 of 2021. However, it also means that the latest M4 Macs can run Monterey in a virtual machine, even though the oldest macOS they can boot into is Sequoia.
When the host or guest macOS is Monterey, sharing folders between them isn’t supported, and the only way to share is through network-based file sharing, which is less convenient. Display support was enhanced in Ventura, which again is required on both guest and host for it to be available.
Support for iCloud and iCloud Drive access didn’t become available in VMs until Sequoia, and now requires that both the guest and host must be running macOS 15.0 or later. As VMs that support these features are structurally different from earlier VMs, this also means those VMs that have been upgraded from an earlier macOS still can’t support iCloud or iCloud Drive. Only those built from the start to support Sequoia on a Sequoia host can support them.
Virtualisation can also have limited forward support, and is widely used to run beta-releases of the next version of macOS. This should be straightforward within the same major version, but testing betas for the next major version commonly requires the installation of additional support software. However, support for running betas is less reliable, and may require creation of a new VM rather than updating.
Many aren’t aware that Apple’s macOS licences do cover its use in VMs, in Section 2B(iii), where there’s a limit of two macOS VMs that can be running on a Mac at any time. This is enforced by macOS, and trying to launch a third will be blocked. For the record, the licence also limits the purposes of virtualisation to “(a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.” It’s worth noting that Apple discontinued macOS Server on 21 April 2022, and it’s unsupported for any macOS more recent than Monterey.
Major limitations
The greatest remaining limitation in virtualising macOS on Apple silicon is its complete inability to run apps from the App Store, apart from Apple’s Pages, Numbers and Keynote, when copied across from the host. Even free apps obtained from the App Store can’t be run, although independently distributed apps are likely to be fully supported. This appears to be the result of Apple’s authorisation restrictions, and unless Apple rethinks and reengineers its store policies, it looks unlikely to change.
Some lesser features remain problems. For example, network connections from a VM are always treated as being Ethernet, and there’s no support for them as Wi-Fi. Audio also remains odd, and appears to be only partially supported. Although Sequoia has enabled support for storage devices, earlier macOS was confined to the VM’s disk image and shared folders. Trackpads don’t always work as smoothly as on the host, particularly in older versions of macOS.
Strengths
One of the most important features is full support for running Intel apps using Rosetta 2.
That and other performance is impressive. CPU core-intensive code runs at almost identical speed to that on the host. Geekbench 6 single-core performance is 99% that of the host, although multi-core performance is of course constrained by the number of cores allocated to the VM. Unlike most Intel virtualisers, macOS VMs attain GPU Metal performance only slightly less than the host, with Geekbench 6 Metal down slightly to 94% that of the host.
VMs are mobile between Macs, even when built to support iCloud and iCloud Drive access. Because each VM is effectively self-contained, this is an excellent way to provide access to a customised suite of software with its own settings. As disk images, storage in VMs is normally in sparse file format, so takes a lot less disk space than might be expected. It’s also quick and simple to duplicate a VM for testing, then to delete that duplicate, leaving the original untouched.
Future
Virtualising macOS on Apple silicon has relatively limited value at present, but in the future will become an essential feature for more users. Currently it’s most popular with developers who need to test against multiple versions of macOS, and with researchers, particularly in security, who can lock a VM down with its security protection disabled.
Few apps that ran in Big Sur or Monterey are no longer compatible with Sequoia. As macOS is upgraded and newer Macs are released, that will change, and virtualisation will be the only way of running those apps in the future, much as virtualisation on Intel Macs is for older macOS.
There will also come a time when Apple discontinues support for Rosetta 2 in the current macOS. When that happens, virtualisation will become the only way to run Intel apps on Apple silicon.
However, until App Store apps can run in VMs, for many the future of virtualisation will remain constrained.
Summary
macOS VMs on Apple silicon can:
run Monterey and later on any model, but not Big Sur or Intel macOS;
run most betas of the next release of macOS;
run Intel apps using Rosetta 2;
deliver near-normal CPU and GPU performance;
access iCloud and iCloud Drive only when both host and guest are running Sequoia or later;
but they can’t run any App Store apps except for Pages, Numbers and Keynote.
One of the features of CPU cores in Apple silicon Macs is that they aren’t run at a single standard frequency or clock speed, but that varies depending on macOS. Moreover, those frequencies not only differ between generations, so aren’t the same in M2 chips as in the M1, but they also differ between variants within the same family. This article gives frequencies for each of the chips released to date, and considers how and why they differ. This has only been made possible by the many readers who generously gave their time to provide me with this information: thank you all.
The most reliable method of discovering which frequencies are available is using the command tool powermetrics. This lists frequencies for P and E cores, and this article assumes that those it gives are correct. Although it’s most likely that these frequencies aren’t baked into silicon, so could be changed, I’ve seen no evidence to suggest that Apple has done that in any release Mac.
Frequencies
If powermetrics is to be believed, then the maximum frequencies of each of the CPU cores used in each generation differ from some of those you’ll see quoted elsewhere. Correct values should be:
M1 E 2064 MHz or 2.1 GHz; P 3228 MHz or 3.2 GHz;
M2 E 2424 MHz or 2.4 GHz; P 3696 MHz or 3.7 GHz;
M3 E 2748 MHz or 2.7 GHz; P 4056 MHz or 4.1 GHz;
M4 E 2892 MHz or 2.9 GHz; P 4512 MHz or 4.5 GHz.
However, not all variants within a family can use those maximum frequencies. The full table of frequencies reported by powermetrics is:
This is available for download as a Numbers spreadsheet and in CSV format here: mxfreqs
Why those frequencies?
Depending on workload, thread Quality of Service, power mode, and thermal status, macOS sets the frequency for each cluster of CPU cores. Those used range between the minimum or idle, and the maximum, usually given as the core’s ‘clock speed’ and an indication of its maximum potential performance. In between those are as many as 17 intermediate frequencies giving cores great flexibility in performance, power and energy use. Core design and development uses sophisticated models to select idle and maximum frequencies, and undoubtedly to determine those in between.
Looking at the table, it would be easy to assume those numbers are chosen arbitrarily, but when expressed appropriately I think you can see there’s more to them. To look at frequency steps and the frequencies chosen for them, let me explain how I have converted raw frequencies to make them comparable.
First, I work out the steps as evenly spaced points along a line from 0.0, representing idle, to 1.0, representing the core’s maximum frequency. For each of those evenly spaced steps, I calculate a normalised frequency, as (Fmax – Fstep)/(Fmax – Fidle)
where Fidle is the idle (lowest) frequency value, Fmax is the highest, and Fstep is the actual frequency set for that step.
For example, say a core has an idle frequency of 500 MHz, a maximum of 1,500 MHz, and only one step between those. Its steps will be 0.0, 0.5 and 1.0, and if the relationship is linear, then the frequency set by that intermediate step will be 1,000 MHz. If it’s greater than that, the relationship will be non-linear, tending to higher frequency for that step.
I’ll start with the E cores, as they’re simplest and have fewer steps.
E cores
For the M1, Apple didn’t try any tricks with the frequency of its E cores. There are just three intermediate steps, evenly spaced at 0.25, 0.5 and 0.75, and that’s the same with all E cores regardless of variant, from the base up to the Ultra.
With the M2, shown here in red, Apple added an extra step, and in the base M2 there’s also a lower idle frequency, not shown here. What is obvious is that those intermediate frequencies have been increased relative to those of the M1, turning the straight line into a curve.
The M3, shown here in blue, and M4, in purple, deviate even further from the line of the M1, with more steps and relatively higher frequencies.
This shows progress from the M1 in black to the M4 in purple, whose frequencies follow the polynomial shown.
Across the families, intermediate frequencies are most apparent in the E cores, where background threads are run at lower frequencies, and high-QoS threads that should have been run on P cores are run at higher frequencies. In M1 Pro and Max variants, with their two-core E clusters, macOS increases the E cluster frequency when they are running two threads to improve performance and compensate for their small cluster size.
P cores
With P core frequencies, the initial design for the M1 is different. The majority of the frequency steps follow a straight line still, but with a steeper gradient (1.23 against 1.00). Then in the upper quarter of the frequency range, above the step at 0.71, that line eases off to the maximum. This gives finer control of frequency over higher frequencies, and those higher frequencies are also reduced slightly in the base M1 compared to those here from the Pro, Max and Ultra.
In the M2 family, Apple divided frequencies into two: base and Pro variants have two less steps, with the base having a lower idle frequency. Shown here in red are those for the M2 Max, which are faired into a polynomial curve. That increases frequencies lower down, reduces them slightly at the upper end, then has a significantly higher maximum frequency.
Apple continued to tweak the P curves in the M3 (blue) and M4 (purple), with increasing numbers of steps but the same finer control at the upper end.
Here’s the comparison between M1 Max and M4 Max, with the same underlying ideas, but substantial differences. In the M4, each of the three variants released so far is different. The base M4 has a lower idle and maximum, the M4 Pro has a higher idle and maximum but one less step between them, and the M4 Max adds another step to the Pro’s series.
Significance
Apple’s engineers have clearly put considerable effort into picking optimised frequencies for each of the families and variants within them. If you still think that this is all fine detail and only the maximum frequencies count, then you might like to ponder why so much care has gone into selecting those intermediate frequencies, and how they’ve changed since the M1. Both P and E cores spend a lot of their time running at these carefully chosen frequencies.
When Apple silicon Macs were first released, they brought a new secure boot process with a huge advantage over that of T2 Intel Macs: it was possible to boot them from an external disk without affecting their security. This is because all the crucial steps to secure boot processes are run from the Boot ROM and internal SSD.
The first snag with this was that hardly anyone was able to create a usable external boot disk for some months after those M1 Macs shipped. On 18 December 2020 I wrote here how I wished I could explain how to do that successfully, “but like many other M1 owners, all that I’ve tried so far has failed.” The only reader who reported that he had found the secret was Mike Bombich of Carbon Copy Cloner fame. Four days later, I had my first success, and wrote up the instructions, requiring a Thunderbolt 3 SSD connected to “one of your M1 Mac’s Thunderbolt ports”. However, trying to repeat that with a USB-C NVMe drive resulted in failure without apparent cause.
That article attracted a total of 109 comments, many of them from others who had tried, tried all sorts of workarounds, tried one last time, and still failed. By February 2021, the procedure remained as unreliable as ever, when I lamented that external boot disks still don’t work properly with M1 Macs. Among the comments are statements such as “It was no small task, took two months of messing around”. It wasn’t until the end of May, with Big Sur 11.4, that creating an external bootable disk came close to being reliable. I summarised the whole saga here.
The problems had certainly lessened, sufficient to consider what type of disk to boot from, but there were still inexplicable failures. Of note in that last link is the fact that all my successful tests had used the same Thunderbolt port on my Mac Studio. But why should we have noted which ports worked, and which were unreliable?
Since then, focus has shifted to matters of ownership and LocalPolicy, which have taken much of the blame for failures. Last week, when I was updating my instructions for creating bootable external disks, I happened to find Apple’s recent article on the subject.
This was the first time I had seen any warning of failures when the external disk is connected to the DFU port: “If you’re using a Mac with Apple silicon, plug your storage device into any compatible port except the DFU port. Find out how to identify the DFU port. Once the installation is completed, you can connect your storage device to any compatible port, including the DFU port.” That article was published on 1 October 2024, with a screenshot dating from macOS Sonoma.
Apple repeats that warning in its linked article on identifying the DFU port: “For certain tasks, such as reviving or restoring firmware or installing macOS on an external storage device, you need to know the location of your computer’s DFU (device firmware update) port.” That wasn’t published until 9 December 2024.
To understand why one of the USB-C ports on every Apple silicon Mac might be different, we need to go back to the start of its boot process, when it’s running from the Boot ROM and before that Mac has even got as far as its Low-Level Bootloader (LLB). One of the functions of its Boot ROM is to detect and if necessary engage DFU mode. To do that it has to initialise one of the USB-C ports, although it doesn’t do so with Thunderbolt support, which is why DFU connections are run using plain USB and not Thunderbolt. That’s done for simplicity, to keep the code in the Boot ROM to a minimum, and for more robust security.
That first port is designated as Bus 0 using Receptacle 1, which thus becomes the Mac’s DFU port. From the information so recently released by Apple, that port remains different, and when it comes to be used to create LocalPolicy for a bootable external disk, it fails. Thus if you try to install a bootable external disk through the DFU port, it’s doomed to fail.
Given that this limitation applies to all Apple silicon Macs, including those M1 models with Boot ROMs dating from 2020, and isn’t apparently limited to recent versions of macOS and their firmware, this appears to have been a problem all the way along, and at least a contributor to all those failed attempts to install bootable external disks, if not a primary cause. Since late 2020, and not disclosed until four years later.
Looking back at the comments made here at the time, these problems were sufficient deterrent to many who had been considering upgrading to Apple silicon at that time. When such an important feature of all previous Macs is at best tricky and unreliable, potential purchasers were understandably reluctant to pay for what was in so many other respects a triumph for Apple’s engineering teams.
I now look back on all those wasted days, weeks even, trying to get something to work that Apple must have known had a good chance of failing. Is it surprising that my sense of relief in finally learning one of the causes of all that wasted time and effort is overwhelmed with the anger that we’ve had to wait four years to be told one of the causes? And even now it’s hidden away in support notes that we only discover by accident.
Since Apple released the first M1 Macs over four years ago, I’ve been guilty of making the assumption that P and E cores used in the variants (base, Pro, Max and Ultra) in each family are identical. Thanks to the persistence of Thomas, I have learned the error of my ways and can now tell you that, while their hardware might be the same, there’s at least one significant difference between some, their operating frequencies, or clock speeds.
This all came to light when I claimed that the E cores in M4 family chips have a maximum frequency of 2,592 MHz, and Thomas tried to correct me by informing me that his have a maximum of 2,892 MHz, a substantial 300 MHz greater. His are in a base M4, mine in an M4 Pro, which seems even stranger, as the trend is for faster CPUs to run at higher frequencies, and that’s true when you compare their P cores: his can only rise to 4,462 MHz, while mine are slightly faster at 4,512 MHz.
The lesson is learned: E and P cores within the same family can have different operating frequencies. Going back to look at my records of the M1 family, I then realised that, while their E cores have identical frequencies, the P core maximum in a base variant is 3,204 MHz, while Pro and Max variants can run up to 3,228 MHz. Although that difference of only 24 MHz is far less, it can’t have occurred by accident.
The purpose of this article is to show the core frequencies that I have already measured [, and ask for your help in filling in the blanks in this table – no longer required, thank you]
Frequency table
The only variant I was missing from those in the M1 family is the M1 Ultra.
I didn’t have any M2 Macs at all, as we decided to skip them and our only M2 chip is in my wife’s iPad Pro. I now have all four, thank you.
I only had one in the M3 family, the M3 Pro in my MacBook Pro, but have all of them now.
Thanks to Thomas, I already have two from the M4 family, the base and Pro variants, and I now have an M4 Max completing these before the Ultra comes later this year.
How to report frequencies
If you’re able to add to this collection, please open Terminal and run the command sudo powermetrics -n 1 -s cpu_power which then prompts you for your admin password. A few seconds later the window will fill with a single set of measurements looking like this:
All I’d like is a copy containing 3 lines from that:
Machine model at the top, to tell me which Mac it is, thus which chip.
E-Cluster HW active residency, which contains a list of frequencies for the E cores.
P-Cluster HW active residency, which contains a longer list of frequencies for the P cores.
To help, I have highlighted those three lines in the screenshot above.
I now have all the frequency sets that I needed to complete the table.
Reward
I have added your entries to my Numbers spreadsheet, and will make that available for free download from here, so anyone who wants to check those frequencies can do so.
Frequency information also builds our understanding of Apple silicon chips. My next questions are going to be why there are those differences, and whether they significantly affect the performance of our Macs.
Thank you for helping, and thanks to Thomas for demonstrating that CPU cores of the same type aren’t the same after all.
Postscript
Thank you to all who responded so quickly. I now have all the frequencies and no longer require any more, thank you. I will post an updated table with a brief analysis on Monday. There are a lot of differences, many of them surprisingly subtle!
Login
