<div dir="ltr"><div dir="auto"><div dir="ltr"><div dir="auto"><div dir="ltr"><div dir="auto"><div>I'd posted information regarding M.2 Nvme heating and file transfer times on another thread and I have since installed this heat-sink. It has made enough of a difference that I thought I'd update.</div><div><br></div><div><a href="https://www.newegg.ca/p/35Y-005D-00007?Item=9SIADDZ6YW3437" rel="noreferrer noreferrer" target="_blank">https://www.newegg.ca/p/35Y-005D-00007?Item=9SIADDZ6YW3437</a><br></div><div><br></div><div>While the sales blah said it is mandatory to use the supplied thermal pads, it came with three pads layered in plastic backing and no instructions. I used the two thinner pink ones and didn't realize at the time that the thicker blue one came apart as little blue squares. On reflection it looks like these were intended for padding the backing-plane around the chips because the sales picture show's a blue pad protruding from the end of the enclosure but I'd have to remove it from the slot again to reapply those pads. It was trickier to install this go around with my slightly arthritic fingers and all that bulk around it so I'm waiting on that.</div><div><br></div><div>This copy from a 512GiB WD Black Nvme in a USB-C enclosure was done using pipe viewer in the console as opposed to the Nautilus file widget. So in comparing apples to oranges ymmv but the previous Nautilus copy from my installed SSD which was formatted to ext4 took almost 15 minutes, slowing to 95MiB/s about two thirds of the way through the copy. This copy from a NTFS file system on Nvme in an external enclosure via USB-C happened in 4min and hardly wavered from 500MiB/s. </div><div><br></div><div dir="ltr">[R3eiter@archon ~]$ pv /run/media/R3eiter/..path to 512GiB USB-C../backup.tar.gz > /run/media/R3eiter/..path to 1TB Nvme../backup.tar.gz<br> 118GiB 0:03:56 [ 512MiB/s] [================================>] 100% <br></div><div dir="ltr"><br></div><div dir="ltr">However copying from one place to another on the 1TB Nvme seems to have crunched it's on-board cache. In the last minute of this copy, speed dropped from around 500MiB/s to 25MiB/s with an occasional leap up to 475MiB/s. </div><div dir="ltr"><br></div><div dir="ltr">[R3eiter@archon ~]$ pv /run/media/R3eiter/DATA/Nvme/bak/backup.tar.gz > /run/media/R3eiter/DATA/Nvme/backup.tar.gz <br> 118GiB 0:06:35 [ 307MiB/s] [================================>] 100% <br></div><div dir="ltr"><br></div><div dir="ltr">Booting from Nvme sure is is quick. I took Hugh's advice and masked PolicyKit in order to deal with a very slow shutdown watchdog on rebooting. I also masked Plymouth, this shaved the total boot time down a bit more than a second. Around ten seconds</div><div>on the SSD and 7 seconds on the Nvme. <br></div><div dir="auto"><br></div><div dir="auto">F30 seems to have glossed over the grub boot screen while the Plymouth graphics widget was chewing up almost 3 seconds. I only left PolicyKit active long enough to install a proprietary Nvidia driver which is now available from the software apps repo for F30. I did this because F30 now defaults to Wayland which doesn't play well with Nvidia cards. Hopefully this will change. </div><div><br></div><div>I used the F30 software install app to do this Nvidia update because I had a very odd experience with the gui for the bios setup. After my last firmware update I had to enable VT-d in bios from the keyboard without the mouse plugged in order to stop the output freezing. There was also a problem with cold booting the OS (when I upgraded F27 to 28 and then 29) while a tv was plugged into the Nvidia card via hdmi and a monitor on display port. Not being able to decide which output of the Nvidia card to recognize, the system woke neither. </div><div><br></div><div dir="auto">Heres what my current Fedora 30 startup info shows.</div><div dir="auto"><br></div><div dir="ltr">[R3eiter@archon ~]$ sudo systemd-analyze <br>Startup finished in 1.257s (kernel) + 1.413s (initrd) + 4.429s (userspace) = 7.101s <br>graphical.target reached after 4.421s in userspace</div><div dir="ltr"><br>[R3eiter@archon ~]$ sudo systemd-analyze blame<br> 2.484s systemd-udev-settle.service<br> 609ms dracut-initqueue.service<br> 573ms initrd-switch-root.service<br> 569ms lvm2-monitor.service<br> 527ms systemd-logind.service<br> 412ms firewalld.service<br> 360ms akmods.service<br> 302ms udisks2.service<br> 296ms libvirtd.service<br> 251ms systemd-resolved.service<br> 224ms systemd-machined.service<br> 205ms lvm2-pvscan@259:2.service<br> 198ms sssd.service<br> 187ms systemd-udevd.service<br> 173ms systemd-journal-flush.service<br> 148ms systemd-journald.service<br> 129ms dracut-pre-pivot.service<br> 127ms user@42.service<br> 108ms ModemManager.service<br> 106ms upower.service<br> 96ms avahi-daemon.service<br> 94ms user@1000.service<br> 85ms bluetooth.service</div><div dir="ltr"><br></div><div dir="ltr">This post is obviously more seat of the pants than science, but there are very few situations where a user can see with the naked eye that performance was sub-optimal. This was one of them. <br><br></div><div dir="ltr"><br></div></div>
</div></div>
</div></div>
</div>