[GTALUG] Nvme thermal throttling

[Russell Reiter]

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.

https://www.newegg.ca/p/35Y-005D-00007?Item=9SIADDZ6YW3437

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.

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.

[R3eiter at archon ~]$ pv /run/media/R3eiter/..path to 512GiB
USB-C../backup.tar.gz > /run/media/R3eiter/..path to 1TB
Nvme../backup.tar.gz
 118GiB 0:03:56 [ 512MiB/s] [================================>] 100%

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.

[R3eiter at archon ~]$ pv /run/media/R3eiter/DATA/Nvme/bak/backup.tar.gz >
/run/media/R3eiter/DATA/Nvme/backup.tar.gz
 118GiB 0:06:35 [ 307MiB/s] [================================>] 100%

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
on the SSD and 7 seconds on the Nvme.

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.

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.

Heres what my current Fedora 30 startup info shows.

[R3eiter at archon ~]$ sudo systemd-analyze
Startup finished in 1.257s (kernel) + 1.413s (initrd) + 4.429s (userspace)
= 7.101s
graphical.target reached after 4.421s in userspace

[R3eiter at archon ~]$ sudo systemd-analyze blame
          2.484s systemd-udev-settle.service
           609ms dracut-initqueue.service
           573ms initrd-switch-root.service
           569ms lvm2-monitor.service
           527ms systemd-logind.service
           412ms firewalld.service
           360ms akmods.service
           302ms udisks2.service
           296ms libvirtd.service
           251ms systemd-resolved.service
           224ms systemd-machined.service
           205ms lvm2-pvscan at 259:2.service
           198ms sssd.service
           187ms systemd-udevd.service
           173ms systemd-journal-flush.service
           148ms systemd-journald.service
           129ms dracut-pre-pivot.service
           127ms user at 42.service
           108ms ModemManager.service
           106ms upower.service
            96ms avahi-daemon.service
            94ms user at 1000.service
            85ms bluetooth.service

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20190603/0eb7b3ec/attachment.html>