Upgrade Raspberry Pi 4 with a NVMe boot drive

Up to 2 m over copper, longer over active optical. Why? Because of insanely low latency and very high bandwidth (PCIe gen 3 x4 in 2010!). No kernel involvement, app direct to storage. Way ahead of the time.

I was careful to only quote the first sentence of the comment. I understand and agree with the point being made in the remainder of the comment.

I also think the "default experience" matters in terms of web browsers. Why do they all default to Javascript and cookies enabled. In this case, and there are hundreds of thousands of others, neither was technically necessary to read the blog.

Some of the images do not load when Javascript is disabled because the web developer has chosen to include three different-sized copies of the same image and use Javascript to emulate a "zoom" effect.

Quick fix: remove the <noscript> tags

   curl https://alexellisuk.medium.com/upgrade-your-raspberry-pi-4-with-a-nvme-boot-drive-d9ab4e8aa3c2 |sed 's/<noscript>//g;s/<.noscript>//g' > 1.htm

   firefox ./1.htm

Note you can still zoom on these images. Right-click and open the image in a new tab, then zoom. Or you can open the larger versions in a browser tab and then zoom. The full URLs for all different-sized copies of images can be seen with view source.

Intel has Thunderbolt integrated onto their CPU, which seems natural & like what I would want in the future from everyone.

Current Intel host-adapters seem to be ~$10 for the dual-port chip itself[1] (JHL8540). Not sure how much else it adds to the bill-of-material beyond a regular USB port! Adding it direct to the CPU would be a wonderful way to save space, & significantly reduce how hard it is to implement, since one would no longer need to route USB and PCIe and power to this extra chip.

I wouldn't expect Thunderbolt support on the low end for a long time. But I really do think it's really time that cpu makers begin offering it onboard. They already need to start moving towards USB4. Adding PCIe as well would be a courtesy, & a big enabler, for their customers. Hopefully we see these great awesome futures begin arriving in a more well-distributed manner.

[1] https://www.mouser.com/new/intel/intel-8000-thunderbolt-4-co...

Intel's reference designs for thunderbolt are behind NDAs so it's a pain in the ass to implement on a PCB and I don't think the controllers themselves (or their datasheets) are easily sourceable either. The Pi foundation has probably got the pull to do it but it would take quite a bit of effort since it would make the Pi an easily available competing reference design, possibly running into internal politics at Intel.

SATA III is 600MB/s max. So either something is funky with the hdparm test (host side cache?) or it's not SATA.

It's not quite that bad.

A M.2 SATA SSD will fit into any socket designed for M.2 SATA or M.2 PCIe SSDs, without damage. A M.2 PCIe SSD that only uses two PCIe lanes will fit into any socket designed for M.2 SATA or M.2 PCIe SSDs, without damage.

The only way to run into trouble is to force a M.2 PCIe SSD keyed for four lanes of PCIe into a M.2 socket keyed for SATA only with no PCIe lanes. Forcing this requires you to install the drive upside down and overcome the 0.5mm misalignment of the 1.2mm wide notch in the drive (meant to be filled by a 1.1mm key in the slot).

If you merely install a SATA SSD in a slot only wired for PCIe, or a PCIe x2 SSD into a slot only wired for SATA, the drive will fail to work but nothing will be damaged.

(You could theoretically also end up in trouble by forcing a SATA or PCIe x2 M.2 SSD into an appropriate slot, but upside down. However, this requires considerably more stupidity on the part of the user because in this scenario the SSD has two notches in the connector, so it is fairly obvious that any mechanical difficulty with installation could be due to having the card upside down. When installing a drive with only one notch, it's less obvious that the difficulty arises from a fundamental and intentional incompatibility.)

> I'd use a SATA M.2 if needed to save 40% of the cost on the same size SSD. Or just a random thumb drive I have around.

There are now lots of low-end M.2 NVMe SSDs on the market, and M.2 SATA SSDs are becoming uncommon. So there's no price remaining price advantage for M.2 SATA over M.2 NVMe—certainly not 40%—and it is not uncommon to find M.2 NVMe sale prices that are better than any M.2 SATA SSD price, since the more popular NVMe SSDs get better and more frequent discounts than the niche M.2 SATA SSDs.

And the M.2 SSDs on the market with the lowest absolute cost (rather than per GB) are usually the Intel Optane Memory 16GB NVMe SSDs that were intended for use as cache devices, but have enough capacity for lots of embedded Linux use cases while also outperforming SATA SSDs of any capacity.

It very much depends on the particular drive, with both controller and NAND choice affecting power draw and efficiency.

On a performance per Watt basis, most M.2 NVMe SSDs are much more efficient than M.2 SATA SSDs. The most efficient M.2 NVMe SSDs are also at least competitive with M.2 SATA SSDs in terms of absolute power consumption, despite outperforming the SATA SSDs by at least a factor of 2-3x. Power consumption from a M.2 NVMe SSD will also drop slightly when only one or two of its four PCIe lanes are used, which is the case when the drive is behind a USB to NVMe bridge.

For example, comparing a SK hynix NVMe drive against of dozens of other M.2 NVMe and 2.5" SATA drives: https://images.anandtech.com/doci/16012/rr-all.png Unfortunately, I don't think there are any M.2 SATA results in there, and those are often a little bit more efficient than their 2.5" counterparts (running off 3.3V rather than 5V, but stepping it down to at least one or two lower voltages on the drive in either case).

A single PCIe lane can draw 0.5 A, 4x rises to 2 A.

Separately, (random top Google result cutpaste):

    Architectural-level power optimization can target different system
    components such as CPU, caches, main memory,and buses [5, 6, 22, 4]. Power
    spent in off-chip buses can be a significant portion of the overall power
    budget. As an example, the core power consumption of Intel Celeron at
    266MHz is 16W, while its off-chip bus (for a standard configuration)
    operating at 133 MHz consumes 3.3W [12, 13]. The contribution of off-chip
    bus power consumption to the overall power budget increases even more for
    embedded systems with low-power processor cores and memories, making
    off-chip  buses  a  potential  candidate  for  power  optimization. Figure
    1 shows the power consumption due to off-chip data bus for several embedded
    benchmark codes as a percentage of the overall power consumption (which
    includes processor data path, caches, buses, TLB, register file,
    instruction issue logic, clock, and off-chip memory) for an
    embedded processor.  From this figure, we see that the off-chip data bus
    consumes between 9.8% and 23.2% of the total power consumed by the system
    depending on the benchmark being run. So, reducing the power consumption
    of the off-chip data bus would reduce the overall power consumption of
    the system to a considerable extent

More lanes on the freeway.

> jiggles around in place

I don't want to defend USB too heavily (as you say, it is certainly not "industrial grade," but I don't know what the equivalent of something simple and very strong like a Hubbell twist-lock connector would be in data transfer terms, and that's something to contemplate) but this really shouldn't happen with any halfway decent cables or hardware. It doesn't apply to the Raspberry Pi 4 in my experience, or any of my laptops or PCs. Phones and micro-USB are, of course, a special case and uniquely horrible.

> SCSI cables were fine

Except when they weren't, and then you'd have to spend fifty bucks (whatever that equals in 2020 dollars) to test and see if the cable was what was failing you, or the termination, or the jumper settings...

I'm running several Pi's from SD card, some for years, and the only issue I had was with one that randomly crashed.

Measured the resistance of the "USB charging cable" I had used for it and found it was 1 Ohm! So when the Pi peaked at 1A current draw, the cable dropped 1V.

Swapped it out for something proper (<0.1 Ohm), and haven't had issues since.

Presumably using an enterprise-grade NVMe SSD with power loss protection capacitors would avoid such trouble. Some of those have reasonably low power consumption under load, but they're all bad at idle compared to client/consumer SSDs. But now you also have me wondering about Intel's Optane cache SSD modules, which like enterprise SSDs don't have any volatile caching, and they're also cheap enough to make some sense in an RPi context. I'm tempted to do some voltage margin testing on one to see where it browns out compared to a typical consumer SSD.