No worries. At least now we know to avoid the XPG SX8200 Pro 1TB.
Yeah, I was a bit hesitant with the Blue. But I figured that the bottleneck will be the interface to the Reform. And that will allow it to keep up with the read/writes without any DRAM cache.
I tested to increase the sample size to 20M and the result was about the same. Maybe I should gone higher, but I don’t want to put too much unnecessary wear on it.
I agree that those writes looks a bit suspicious, given that it should be able to read faster than writing. If the data sheet is to be trusted (2400MB/s read, 1950MB/s write). But both are way above the speed that the one PCIe lane can handle. Like you said the limiting factor will be the one PCIe lane.
Now you have me thinking, I looked at the chip datasheet and it has 2x PCIe 2.0 interfaces, so with the one lane there should be a bandwidth of 500MB/s So the write speed isn’t out of the realm of possible.
Though now I’m wondering what the bottleneck is that most NVMe drives we have are getting <300MB/s. Wondering if it’s just the controllers in most drives being unhappy with a single 2.0 lane, a limitation of the SoC, or perhaps a kernel issue?
My drive should be capable of 3500MB/s reads on 4x 3.0 (3.94 GB/s max), it should have no trouble saturating a 2.0 link.
I bought a 1TB SK Hynix Gold P31, which is one of the drives recommended by Wirecutter. It seems to be working fine after a couple days. I’m seeing similar numbers to what others have posted: ~300 MB/s reads and ~380 MB/s writes.
It’s currently unencrypted, but I’m thinking about reformatting it and encrypting with LUKS. Does anyone know if there’s a significant performance impact using LUKS on the Reform?
Hey everyone - I’d be happy to try out a few of my nvme drives to add to the list, but simply saying that a drive officially “works” or not is a little subjective. What testing procedures can we agree on? Are we talking something relatively scientific where we write/read sequential/random blocks and record performance, checking that it passes CRC and exceeds some threshold of performance, or do we say “I saved a copy of The Matrix on the drive and was able to play it back?” If we’re preferring the former option, is there a script or an existing benchmarking tool we can all agree to use? Perhaps just verify lspci and lsblk output and, if all good, run a gnome-disks benchmark as mentioned earlier in this thread?
I’m all for more scientific than subjective. fio is a good tool for testing performance. Ars Technica has a good article on how to use it: here. It might be a bit overkill, so gnome-disks benchmark could be good enough.
At least lspci and lsblk should be the first criteria to check.
“I saved a copy of The Matrix on the dirve and was able to play it back” is hard to reproduce
My 2 cents: I personally used the gnome-disks benchmark to determine the best I/O perf vs price ratio when selecting the 32GB MicroSD cards that ship with Reform. The graphs were pretty useful to see differences in buffering etc.
I’m using a Seagate BarraCuda 1 TB drive with no problems. With encryption turned on, hdparm reports a read speed of 172 MB/sec. gnome-disks reports 292.5 MB/s read, 333.7 MB/s write on the disk itself (which by my understanding should be the unencrypted speed).
I’d advise steering away from wd green as well, had a SATA one, it had no cache so performance was awful and it started silently corrupting data 3 days after the warranty expired. sector tests throw billions of errors. it’s completely knackered.
I have similar problems with resume from suspend with a “Kingston NV2 NVMe SSD, 1 TB, M.2 PCIe”. After resuming from suspend with a vanilla sysimage-v3 copied from the SD-Card onto NVMe with reform-setup-encrypted-nvme and kernel 5.19 I get:
You may need to disregard my last two posts. I now tested a 1 TB Transcend MTE220S with my reform which is the same drive that comes with the DIY kit and is confirmed working with suspend by Lukas. The drive doesn’t work for me when resuming for suspend. This might mean that something else in my unit is broken and that the drives I had problems with before are actually fine.