Thanks for the tip... I may do the same.
I completed my CPU re-paste yesterday with Thermal Grizzly Conductonaut. I also got a rough temperature drop of around 10C: the system idles and runs much cooler according to the Intel Power Gadget. I've tweaked the BIOS fan settings to minimize noise and have screwed the VESA mount to the underside of my wooden desk near the far corner: with that additional noise shielding the NUC is now generally so quiet that the only perceptible sound is a nearby spinning disk array in my NAS.
Any problems with slow boot with APFS?
(trim, which is default with NVMe, is proving to cause slow boot [fsck or equivalent running each boot])
Yes -- it's painfully slow taking several minutes. I rarely reboot and just lock the machine overnight with displays automatically entering power-save mode.
On my verbose boots I see "quickcheck only; filesystem clean" and no logs relating to TRIM. Unfortunately nothing in the system boot log either.
When I boot into recovery, the system blocks for some time on initial SSD disk activity: for example, when performing a `diskutil apfs list`. It might be a similar issue here? It's almost like there's some kind of timeout being reached.
Some earlier HS betas booted much faster with otherwise the same setup as I have now. I do remember seeing a lot of TRIM warnings at one stage, but not on the 10.13 release.
What do you see on your system?
You find any documentation on the dart kernel flag?
The only thing I could find on the DART (Device Address Resolution Table)
is discussed in some Apple docs that you may have already seen. As others have also mentioned, the DART allows PCI hardware memory mappings; in the docs above they specifically mention its use on a 64-bit system to map addresses to PCI hardware running in 32-bit address mode and otherwise avoid a bounce buffer copy. I guess the same MMU can be leveraged in virtualization: Docker is using the macOS Hypervisor framework, which may be leveraging the DART?
To confuse the issue a bit more, I just did a clean reboot with `dart=0` and Docker still worked, with
$ sysctl kern.hv_support
kern.hv_support: 1
This wasn't the case when I tried it the first time. I'm now not 100% sure what the best option is. I've since removed the `dart=1` boot arg to let the system do its thing. Docker runs fine on every boot this way. This did not affect the slow boot time further.