Unboxing and review of SanDisk 64GB microSDXC High Endurance Card

Dashcams: they can be a crucial tool when reconstructing events in a vehicular incident, or a source of entertainment when watching compilations on YouTube. Like any modern device, they generally use SD or microSD cards as their storage medium. However, not all cards are created equal.

Cheaper cards, like SanDisk’s Ultra lineup, use cheaper TLC (triple-level cell) NAND Flash that is ill-suited to the harsh working conditions of a dashcam. Not only does the card have to endure temperature extremes, the constant writes can burn through the Flash’s write cycles in short order. In fact, SanDisk specifically denounces this line of cards for use in continuous-recording applications.

The solution: high-endurance memory cards! These cards (at least in theory) use more durable MLC or even SLC NAND Flash, which can take many more write cycles. I purchased the 64-gigabyte model, the SDSQQNR-064G-G46A.

Unboxing

The card’s packaging isn’t much different than SanDisk’s typical microSD card offerings. The paper-and-plastic package includes a small blister pack that holds the microSD card itself and the full-size SD card adapter, without a carrying case (granted, the memory card is expected to stay inside the dashcam for most of its working life).

The packaging also includes a license key for a 1-year subscription to the RescuePRO data recovery software (although in all honesty, you’d be better off using the free PhotoRec software instead).

Endurance Rating

SanDisk’s lineup of high-endurance memory cards are designed for use in very write-intensive workloads, such as constant video recording.

Unfortunately, the endurance specifications for these cards are (probably intentionally) vague, only providing a set number of hours of video recording. However, we can infer a rating with a little bit of math.

SanDisk’s card packaging defines Full HD video to be 26 Mbps, which is equivalent to 3.25 (binary) megabytes per second. This equates to 11,700 megabytes per hour, or 11.426 gigabytes per hour. With a rating of 5,000 hours at this data rate, we get a specified endurance of 57,128.91 gigabytes written, or 55.79 terabytes written (TBW).

Memory cards, like other block-based storage media, often define capacities with decimal prefixes, whereas computers usually binary. A “64-gigabyte” card is really 59.605 binary gigabytes (“gibibytes“) in capacity, but in this blog post I’m using the Windows notation of gigabytes; that is, calculating in binary but displaying as decimal. 😛

Therefore, we get a final calculated P/E (program-erase) cycle count of… 936 cycles. This is more in line with traditional 2D TLC NAND Flash, so I suspect that this rating is either based on different bitrates, or SanDisk is being really, really conservative in their estimates – or heck, maybe this really is just TLC NAND Flash that’s being configured and/or warrantied differently by SanDisk. As much as I am tempted to remove the epoxy coating that covers the manufacturing test pads in order to get a NAND Flash signature directly, I like having a warranty for at least a few years. Maybe I’ll buy another card to try this on…

Card Information

Using an older laptop with a true SD-compliant slot (most newer ones are just USB card readers internally), I was able to grab the card’s metadata from Linux. These information files are found in /sys/block/mmcblkX/device, where X is usually 0 depending on your host machine. Android used to be able to do this as well, but nowadays it’s not possible without a rooted operating system.

Item Value
CID (Card ID) 035744534836344780ed1bbb9e013100
CSD (Card Specific Data) 400e0032db790001dbd37f800a404000
Manufacturer ID 0x03 (SanDisk)
Manufacture Date January 2019
Device Name SH64G
Firmware Version 0x0
Hardware Revision 0x8

Initial Formatting

The card is formatted as exFAT, with a 16 MB offset (that is, the first 16 MB of the card is unallocated), with an allocation unit size of 128 kilobytes. It uses a very basic MBR (Master Boot Record) partition structure, with the first sector being the bare minimum to be recognized as a valid structure.

Performance

Now that I’ve probably irked some of my readers with my usage of decimal and binary prefixes, it’s time to see how fast this card can go. SanDisk’s own ratings for the card are very brief, citing a sequential read/write speed of 100 and 40 MB/s respectively. It is rated for the V30 Video speed classification, which guarantees a minimum of 30 MB/s sequential writes continuously.

All the tests below were performed on my desktop computer using a FCR-HS4 USB 3.0 reader from Kingston, which is based on the Realtek RTS5321 chipset.

CrystalDiskMark

CrystalDiskMark is the de-facto standard for storage benchmarks. I’m using the 64-bit edition of CDM, version 5.2.0.

I/O Type Read Write
Sequential QD32 91.80 MB/s 60.56 MB/s
Sequential 93.33 MB/s 61.66 MB/s
4K Random QD32 8.319 MB/s
2129.7 IOPS
4.004 MB/s
1025.0 IOPS
4K Random 8.121 MB/s
2079.0 IOPS
3.971 MB/s
1016.6 IOPS

The sequential I/O speeds are on par with a modern microSDXC card, and the IOPS aren’t too shabby either; they exceed the IOPS requirements for the A1 performance class which requires R/W IOPS of 1500 and 500 respectively. This could make this type of card a viable option for other write-heavy environments – this includes single-board computers (SBCs) like the Raspberry Pi, where memory card failures due to excessive writes are common.

ATTO Disk Benchmark

The card’s read/write performance levels off at around the 64-kilobyte mark during testing, showing that operations smaller than this incur a significant performance penalty. This may also be indicative of the internal page and block sizes of the NAND Flash itself.

Hard Disk Sentinel

Hard Disk Sentinel comes with a bunch of disk benchmarking tools, including some to test the entire “surface” of a drive. I used the software’s Surface Test tool to measure the card’s performance before and after filling the drive with data – first with random data, then with all zeroes.

Random Seek Test

The Random Seek Test measures the card’s latency when performing random “seeks”, although more accurately it reads a single sector from a random location.

State Average Latency Minimum Latency Maximum Latency
Empty/Initial (0x00) 360 µs 350 µs 420 µs
Random Fill 600 µs 590 µs 670 µs
Zero Fill 600 µs 590 µs 690 µs

The card initially had about 420 microseconds of latency, but after filling the card with random data, this increased to 670 microseconds. Filling the card with all zeroes again did not improve performance, and his isn’t helped by the fact that SD cards generally lack the ability to “TRIM” unused sectors like SSDs or eMMC chips.

Full Surface Read (or at least an attempt)

This is where things get a bit… interesting. It was around this time that I noticed some performance inconsistencies that didn’t show up on other benchmarks. Although the I/O speeds largely matched what my other benchmarks revealed, I noticed frequent dips below normal, often down to the mid-20 MB/s range! I wasn’t sure that this was necessarily the card’s fault (pauses in read/writes could result in performance degradation on a device if it can’t buffer the writes well enough), or if my card reader/operating system/etc. was responsible.

I decided to hold off on publishing the sequential write test until I get this issue figured out – perhaps it’s worthy of a blog post all on its own…

eMMC Adventures, Episode 1: Building my own 64GB memory card with a $6 eMMC chip

As seen on Hackaday!

There’s always some electronics topic that I end up focusing all my efforts on (at least for a certain time), and that topic is now eMMC NAND Flash memory.

Overview

eMMC (sometimes shown as e.MMC or e-MMC) stands for Embedded MultiMediaCard; some manufacturers create their own name like SanDisk’s iNAND or Hynix’s e-NAND. It’s a very common form of Flash storage in smartphones and tablets, even lower-end laptops. The newer versions of the eMMC standard (4.5, 5.0 and 5.1) have placed greater emphasis on random small-block I/O (IOPS, or Input/Output operations per second; eMMC devices can now provide SSD-like performance (>10 MB/s 4KB read/write) without the higher cost and power consumption of a full SATA- or PCIe-based SSD.

MMC and eMMC storage is closely related to the SD card standard everyone knows today. In fact, SD hosts will often be able to use MMC devices without modification (electrically, they are the same, but software-wise SD has a slightly different feature set; for example SD cards have CPRM copy protection but lack the MMC’s TRIM and Secure Erase commands. The “e” in eMMC refers to the fact that the memory is a BGA chip directly soldered (embedded) to the motherboard (this also prevents it from being easily upgraded without the proper tools and know-how.

Continue reading

Review of SanDisk Extreme CompactFlash 32GB (SDCFXS-032G)

After my previous review of a Silicon Power 8GB CompactFlash memory card, I was looking around for more CF cards to review, in the hopes of finding a higher-performing card with S.M.A.R.T. health reporting and the ability of acting as a “fixed disk” (that is, identifying to the system as a hard drive rather than a removable disk), and decided to purchase this memory card from Amazon.

Advertised specifications

The card’s specifications indicate that the CompactFlash card is capable of 120MB/s sequential read and 60MB/s sequential write speeds, has a lifetime warranty and comes with a license key for a 1-year subscription to their RescuePRO data recovery software. It is advertised to have internal RTV (room-temperature vulcanization) silicone potting, has an operational temperature range of -25 to 85 degrees Celsius (-13 to 185 Fahrenheit), and uses their “ESP (Enhanced Super-Parallel) Technology” which I presume is some sort of proprietary multi-channel controller, and is UDMA 7 (167 MB/s maximum interface speed) capable.

Benchmark – Setup

To connect the card to my computer, I used a CompactFlash-to-IDE converter and a Marvell 88SE9128-based SATA/PATA host bus adapter. This allows me to use up to UDMA 6 (133 MB/s maximum interface speed) as UDMA 7 is basically restricted to cameras as it’s only part of the CompactFlash official specifications.

Benchmark – CrystalDiskMark

For this test, I manually zero-filled the card using Hard Disk Sentinel, formatted it with exFAT, then ran CrystalDiskMark, set to 3 runs with a 500MB file size using random data, all zeros (0x00), and all ones (0xFF).

Data Type Test Read (MB/s) Write (MB/s) IOPS Read IOPS Write
Random Sequential 103.2 52.45
512K Random 99.55 29.57
4K Random (QD1) 11.37 0.916 2775.2 223.6
4K Random (QD32) 17.24 1.413 4208.2 344.9
All 0 (0x00) Sequential 104.3 54.25
512K Random 98.27 31.22
4K Random (QD1) 11.36 1.1 2773.3 268.5
4K Random (QD32) 17.39 1.263 4244.5 308.4
All 1 (0xFF) Sequential 104.5 53.95
512K Random 98.05 25.84
4K Random (QD1) 11.19 1.112 2733 271.4
4K Random (QD32) 17.32 1.437 4229.3 351

It appears that there is no significant difference between the tests depending on what data was used for the benchmark.

Benchmark – AS SSD

As with CrystalDiskMark, I zeroed out the card and formatted it as exFAT before running the test.

Test Read Write
Sequential 99.70 MB/s 46.13 MB/s
4K 11.40 MB/s 0.74 MB/s
4K 64 Thread 12.80 MB/s 1.03 MB/s
Access Time 0.389 ms 5.504 ms
Score 34 6
61

Benchmark – Hard Disk Sentinel

I ran three separate benchmarks with Hard Disk Sentinel’s Surface Test feature, using the read and write (both empty and random data) tests, and used the Random Seek Test to measure the card’s responsiveness after filling it with empty and random data.

Test Speed
Read 0x00 95.20 MB/s
Read Random 97.30 MB/s
Write 0x00 49.81 MB/s
Write Random 49.04 MB/s
Seek Time 0x00 0.35 ms
Seek Time Random 0.37 ms

Once again, there does not appear to be any appreciable difference between an empty (zeroed-out) or full card.

Analysis – HWiNFO64

Now that the benchmarks are out of the way, let’s take a look at the card and what it can (and can’t) do. Let’s take a look at the details of the drive…

The card shows up as a regular IDE drive in HWiNFO, and has information about its CHS (Cylinder-Head-Sector) geometries and supported I/O interface speeds. Here we can see the card supports up to UDMA 7 but is running at UDMA 6 as because it is connected to a PC IDE bus.

Now for the kicker: Does the drive identify itself as a fixed or removable disk? Cross your fingers…

NOPE! The SanDisk Extreme CompactFlash card does NOT identify as a fixed disk, but instead as a removable drive. This means that the hopes of using this as a bootable Windows disk are now out the window. [ba-dum-tssh!]

Analysis – Hard Disk Sentinel

Looking at the Overview tab in HDS, something weird is happening. It states that “the hard disk status is PERFECT” yet it has no health or performance percentages available. If I open the Information tab, I can see that the SanDisk Extreme CompactFlash card does NOT support S.M.A.R.T. health reporting. Bummer. Additionally, it appears that Windows does not like removable IDE drives that lack S.M.A.R.T. and instead report garbage data (or data mirrored from another drive in the system).

Looking further inside the Information tab, we can see the features that the memory card does support. It supports DMA, Ultra DMA, APM (advanced power management), write caching, 48-bit LBA (logical block address) addressing, IORDY (flow control), a NOP (no-operation) command, and has the CFA (CompactFlash Association) feature set.

Since the card reported that it supported APM, I tried to enable it but the card refused to accept the command.

Conclusion

Overall, I like this card quite a bit. It has fast sequential I/O and a respectable random read speed. However, this is soiled by the fact that the card is configured to show up as a removable disk, which renders the card unusable as a Windows boot drive, and the lack of S.M.A.R.T. health and temperature reporting makes me a bit uneasy as I cannot track the card’s program-erase cycle count during use.

Oh well. Looks like the hunt for a fast, fixed-disk CompactFlash card continues…

Teardown/review of Silicon Power 8GB 200x CompactFlash memory card

Hooray for nice hand-me-down SLR cameras! I finally have a better camera than the one built into my (now ancient) Samsung Galaxy S II that I use for pictures on this blog. The camera, a Canon EOS 50D, had an 8GB CompactFlash card that I was preparing to erase and reuse, and had problems trying to read out the card’s contents; a few stubborn files would refuse to copy and Explorer would simply hang until I restarted the program or unplugged the card. Additionally, when using my Hard Disk Sentinel program to do a surface scan, it too would freeze when reading a certain sector on the card.

Instead of using a USB-to-CompactFlash adapter (I could not find my card reader and have not seen it for over a year now, come to think of it) I used a CompactFlash-to-PATA adapter, then a PATA-to-SATA adapter so I could directly hook up the card to my computer. In addition to having greater theoretical throughput, it allows me to view the S.M.A.R.T. diagnostic data that the card provides.

Memory card issues and performance

The diagnostic information doesn’t really provide any insight into the health of the card; none of the S.M.A.R.T. attributes are listed as critical, and many of them are listed as vendor-specific. Oh well, at least it gave me some sort of information…

After finding a copy of the card’s contents on my home server (I seem to have previously backed up the card before the corruption occurred but didn’t recall doing so until I had raked through some of my archives), I decided I’d do a full card erase and see if it would cause the card to be usable again. I called up the Surface Test in Hard Disk Sentinel and used its surface-write tool to erase the user-accessible area of the card. A few blocks seemed to write dramatically slower than the rest and repeated write tests did not resolve their sluggishness; I call shenanigans with the memory card’s controller and its reluctance in reallocating problematic sectors…

The card itself isn’t very fast. The sequential I/O of the card is good enough for casual photography, but I would definitely not use this card in an embedded system that uses a CompactFlash as a sort of mini-SSD; even though it shows up in my system as a hard drive (non-removable), its random I/O is quite sluggish and its random write speed is worse than that of a standard hard disk drive.

Teardown

The card itself is a sandwich of aluminum plates, a plastic case and the PCB assembly that holds the controller, Flash memory and the CompactFlash connector. A hobby knife run under the aluminum plate was able to separate the plate from the plastic body; some glue and a couple clips were the only things holding the card together.

The card’s controller is a Phison PS3006, which sports a PCMCIA (and therefore CompactFlash) interface with True IDE (or plain PATA) support. It contains an 8051 microcontroller core with a few components to assist with interfacing with the Flash memory, such as a hardware ECC (error correction code) engine and a small amount of SRAM for a buffer.

The datasheet for the PS3006 doesn’t provide information on the S.M.A.R.T. attributes, nor does it indicate what type of Flash wear-leveling is provided. Given the controller’s limited computing capabilities, I’m thinking it uses a less-complex but less-reliable form of wear leveling, known as dynamic wear leveling (see Micron’s application note for more information). It’s less capable of dealing with memory wearout, but doesn’t require the computing overhead of static wear leveling (which proper SSD controllers use to keep performance up).

The memory is an Intel 29F32G08AAMD2 device, which is an asynchronous MLC NAND Flash memory chip. There are two installed on this card with another two footprints on the PCB being unpopulated, suggesting that the 16GB version of this card has all four footprints populated.

Conclusion

Given the simplicity of the card, I don’t really have much else to add about this card. Either way, it’s lost my trust with regards to holding my photos. I bought a NOS Disk 16GB CF card from Amazon as well as a SanDisk Extreme 32GB, and plan to use the latter to hold my photos, with the former mainly being a simple curiosity of the construction of a card from a lesser-known manufacturer. Hopefully those will also provide S.M.A.R.T. data, as I prefer Flash-based storage devices with some sort of S.M.A.R.T. data capability. (Is it an insatiable thirst for knowledge? A means of doing regular ‘check-ups’ on my storage device? Probably the latter, but maaayyyybe the former as well. 🙂 )

A Little Pick-Me-Up: Samsung 840 EVO SSD slowdowns, and how to fix it (for now…)

There’s been word going around that Samsung’s 840 EVO solid-state drives have an issue where they become really, really slow to read if the data on it has been sitting around for a few months, and I can confirm this is the case as well.

The first half of the drive (which holds a fair amount of static data) was being read at around 30 MB/s, with newer data being read at almost 500 MB/s. That’s a pretty big difference. One thing to note (I didn’t take a screenshot for this) is that although the overall read speed was significantly affected, the read latency was only somewhat slower; only about 10-20 microseconds of extra latency.

To temporarily fix this (at least until Samsung releases a firmware update in the middle of October), I used Hard Disk Sentinel to read and rewrite all of the data on the SSD. Because this involves accessing data that is normally locked by Windows, I made a custom WinPE (a slimmed-down, portable version of Windows that’s used for installation and recovery) image with Hard Disk Sentinel inside it. This allowed me to boot outside of the normal Windows setup, and perform the Read+Write+Read test to refresh all of the data stored on the SSD. Note that this will impart a lot of write activity to the NAND flash in the SSD (hence a chance for increasing wear), but modern SSDs aren’t as delicate as people might think.

HD Sentinel's Refresh Data Area test

Hard Disk Sentinel’s “Refresh Data Area” test

This took about 2 hours on my 250 GB SSD. Afterwards, another read test showed that the drive was working smoothly again.

Will I still buy a Samsung SSD? Absolutely. No data was lost and Samsung did the right thing by acknowledging the issue and also finding a way to fix it, as opposed to simply calling it a non-issue and sweeping it under the rug.

(Part 2 of 2) Microdrive Adventures: Looking into (and butchering) the Hitachi Microdrive and Seagate ST1 CompactFlash hard drives

(Part 1 viewable here)

Content advisory: electronics gore! 😀

refundI sent screenshots from Hard Disk Sentinel to the seller of the microdrives, and they refunded my money but didn’t want the drives back. Even then, it’d probably be a good idea to destroy the drives since re-use of them would be a bit… fraudulent after getting refunded. I decided to throw the drives around to see how well they’d hold up to physical abuse.

The Microdrive died when I whipped it against the concrete floor of my basement, go figure. The impact was strong enough to bend the steel frame but not enough to shatter the glass hard disk inside. Obviously, the disk didn’t spin up or enumerate in Hard Disk Sentinel. Now that the drive’s murder has been accomplished, it’s autopsy time!

The Seagate ST1 was put through a similar treatment, but it died much less gracefully when plugged in. The main controller chip (I think) shorted internally, and after about 15 seconds of being powered up, it released the magic smoke. The board’s plastic liner was melted where the chip shorted out. The drive internals weren’t much different than the Hitachi drives so I didn’t bother taking pictures of the drive’s insides.

After the damage was done, the drives were promptly put in a small plastic bag to be put in an electronics recycle bin.

(Part 1 of 2) Microdrive Adventures: Looking into (and butchering) the Hitachi Microdrive and Seagate ST1 CompactFlash hard drives

A few weeks ago I decided to hop onto eBay and buy a couple microdrives for fun. If you haven’t heard of the term, a microdrive is a hard disk drive that fits into a CompactFlash slot. These were intended to be the future in mobile storage, with 20 GB drives being the biggest around 2006. Of course, these drives proved to be very delicate, and besides, now we get 128 GB microSD cards!

The drives I purchased appeared to be pulled from some old iPod minis. The seller tried to remove the Apple logo with some sort of solvent, but left the smudges behind.

The problem with the iPod mini drives is that their CompactFlash interface is disabled. That is, the drive is really just a PATA drive in a CompactFlash’s body. Few devices that aren’t PCs support CompactFlash cards in this mode.

Being the curious type, I popped the drives into my Sony Clie NX73V, which I still carry with me even though it’s 11 years old 🙂 . It has support for CompactFlash Type I and II (thin and thick, basically), and, according to the properties window in the OS, uses the ATA protocol to talk to the cards. This means it should interface with the cards just fine… right?

First, I popped the Hitachi Microdrive in my Clie. One second after inserting the card, I see a question mark in the memory card’s taskbar icon. No dice.

Then, I moved on to the Seagate ST1. It spun up, but the Clie hung for about 30 seconds before finally displaying “The card cannot be recognized”. However, it did at least enumerate with the OS and I could pull up the manufacturer and model number of the drive.

Hm, well those ideas were dashed pretty quickly. Later, I bought a CompactFlash-to-PATA adapter, and a PATA-to-SATA adapter so I could hook it up to my laptop. From there, I used Hard Disk Sentinel (great software, by the way!) to analyze the drives and see if they have S.M.A.R.T. health reporting…

… and they do, alright! In fact, the drives I purchased were both soon to be dead. The Seagate drive had hundreds of bad sectors and a failing disk head/head actuator. The Hitachi drives had so many reallocated sectors that the drive literally ran out of spares. Too bad the Microdrive didn’t report how many sectors were reallocated though…

The drives themselves were in really bad shape, as seen below:

In the next part, I’ll show the aftermath of both drives. (Content Advisory: electronics gore)