Or: What are the best microSD cards you can get for under $15 in 2024?
If you just want to see my top picks, skip to the Overall Picks section. If you want to read in more detail about how I determined the top picks, read on.
Introduction
MicroSD cards are ubiquitous nowadays, having found applications in a wide variety of consumer devices — including smartphones, digital cameras, and single-board computers. While innovation is continuing to take place in this space, the market has largely matured. There are a wide variety of brands, models, and capacities available today, but it could be argued that consumers see little difference — aside from capacity — from one brand or model of card to the next. This ubiquity has helped to drive prices down to the point where a card able to store hundreds of gigabytes of data can be obtained for less than the price of a single meal at an average restaurant.
As with any popular product, the market is littered with fakes. For example, 1 terabyte microSD cards from major brands — such as SanDisk or Lexar — cost around $70-$100, depending on the specific brand or model. A cursory search on Amazon for a 1 TB microSD card, however, yields off-brand (or no-brand) cards with prices as low as $12.99. How are these brands able to offer their products for far less than their name-brand competitors? In many cases, these cards are what is known as “fake flash” — cards that have been programmed to advertise a certain capacity to their host device, but whose actual capacity is far less. For example, a card advertised as having a capacity of 1 terabyte might have an actual capacity closer to 8 gigabytes. On these cards, the actual storage space is typically located at the beginning of the card’s logical address space; writes that occur beyond the end of the available space are simply discarded, while reads will typically result in all zeroes. Additionally, most filesystem implementations will fill up the available space in a linear fashion. Altogether, this means that the user might not notice anything wrong until they’ve filled the card’s physical space — at which point they will find that the data that was saved beyond the end of the card’s physical space is simply gone and unrecoverable.
Fake flash is not completely worthless, however. If the true amount of physical space can be determined, the card’s partition table can be adjusted so that filesystems do not take up more than the amount of physical space available on the card. But, how well do these cards perform — in terms of performance and durability — compared to their “legitimate” counterparts? Is there value in buying fake flash if the caveat on the amount of available space is known beforehand? This was the question that I sought to answer.
In July 2023, I began purchasing various brands and capacities of microSD cards, and I’ve been testing them continuously since then. Originally I turned to AliExpress, focusing primarily on the cheapest options I could find; however, I’ve since expanded my collection to include some name-brand media as well. I also purchased some name-brand media from Amazon — not only because I was curious to see how they performed as well, but also to act as a sort of baseline for comparison.
On this page, I’m listing the results I’ve obtained so far. Keep in mind that many of the cards I purchased are still undergoing testing, and others are still sitting in the packaging waiting to be tested — I’ll note those in my results and update them once I have results to share.
Disclaimer: These tests are not being sponsored by anyone other than myself. All equipment and materials used have been paid for out of my own pocket. I’ll update this if this ever changes.
Criteria
For each card I purchased, I wanted to be able to answer the following questions:
- Authenticity: Is the card the size it says it is, or is it fake flash?
- Performance: How well does the card perform in reading and writing operations? Does the card perform well enough to merit the various speed class markings that appear on the card or the card’s packaging?
- Endurance: How much data can be written to the card before the card becomes unreliable or fails completely?
Authenticity
On the authenticity front, I’m primarily concerned with whether or not a card is “fake flash”. For the purposes of this survey, I’m defining “fake flash” to mean “(a) SD media whose physical capacity is less than what is advertised to the host via its CSD register, or (b) SD media whose physical capacity is less than 95% of what is printed on the card’s exterior or the product packaging”. (I don’t have a method for determining whether a card has a capacity that is more than what is advertised…yet.)
As a secondary concern, I’m also going to be evaluating whether a card can be considered “skimpy flash”. For the purposes of this survey, I’m defining “skimpy flash” to mean “any flash media whose physical capacity — as advertised to the host via its CSD register — is less than what is printed on the card’s exterior or the product packaging”. And, for the purposes of this survey, sizes will be evaluated using linear scales — that is, 1 terabyte = 1,000,000,000,000 bytes, 1 gigabyte = 1,000,000,000 bytes, and so on. For example, if a card is labelled as being 32GB in size, does it actually have at least 32,000,000,000 bytes of available space, or does it have something closer to 31,500,000,000 bytes of available space?
Why include this criteria? Because it can have a material effect on a user’s experience with a card. Skimpy flash is a problem with name-brand and off-brand media alike — with a couple particular name-brands actually being the worst offenders in my survey (so far). (That said, there are a couple other name-brands that were actually the least offenders as well.) Consider, for example, two 64GB cards I obtained — one from Kioxia (the company formed as a result of Toshiba spinning off their flash memory division in 2018) that had a capacity of about 61.89GB, and one from Lexar that had a capacity of about 64.09GB. This is a difference of almost 2.2GB — or about 18 minutes of 1080p video (at 16Mbps).
Edit 3/13/2024: Some cards support a certain amount of password-protected storage. This feature is known as “CPRM”. I realized that, according to the SD Physical Layer Specification, “Card Capacity means the sum of User Area Capacity and Protected Area Capacity” — and I hadn’t been considering the size of the protected area in my skimp calculations. Going forward, I’ll include skimp measurements in the details section for each card. However, since accessing the protected area generally requires special hardware and software support, and most people don’t use it anyways, I’m not going to include it in the overall results. In addition, some cards indicate that they have a non-zero amount of protected memory, but also don’t support card security — and according to the SD Physical Layer Specification, “[f]or Non CPRM Cards, the Protected Area cannot be accessed.” For these cards, I will note that the protected area is inaccessible and will not provide an adjusted skimp calculation.
Performance
The SD Association has created a number of performance standards for SD cards, each with their own mark. Virtually all SD and microSD cards sold today carry at least one of these marks. I’m concerned with how well cards performed overall, but I’m also concerned with whether or not the card performed well enough to qualify for the markings that it bears — both on the packaging and on the card itself.
As of today, the SD Association has defined the following speed classes:
- Class 2, 4, 6, 10: These speed classes dictate that read and write speeds should be at least 2MB/sec, 4MB/sec, 6MB/sec, and 10MB/sec, respectively. Cards have an application unit (AU) size defined in their SSR register, and write performance is measured by the amount of time taken to write in a sequential fashion to a single AU. (In the case of SDXC and SDUC cards, write performance is measured over a single AU or a 4MB segment of an AU, whichever is smaller.) Read performance, on the other hand, is measured by the amount of time taken to perform 256 random read operations.
- U1 and U3: These speed classes dictate that read and write speeds should be at least 10MB/sec and 30MB/sec, respectively, when operating in UHS-I or UHS-II mode. The semantics of how performance is measured is largely the same as for Class 2/4/6/10.
- Video Speed Class 6, 10, 30, 60, and 90: Version 5 of the SD card specification added a set of video speed classes, as well as some new commands to control the operation of the card and place the card into Video Speed Class recording mode. When operating in this mode, these speed classes dictate that write speeds should be at least 6MB/sec, 10MB/sec, 30MB/sec, 60MB/sec, and 90MB/sec, respectively.
- Application Performance Class 1 and 2: These speed classes dictate a minimum number of random read and write operations per second (where each operation is 4KB in size), as well as a minimum sequential read and write speed of 10MB/sec. Application Performance Class 1 dictates a minimum of 1500 read operations per second and 500 write operations per second, while Application Performance Class 2 dictates a minimum of 4,000 read operations per second and 2,000 write operations per second.
Realistically, I don’t have the ability to perform tests exactly as the SD specification prescribes (although I’m working on that), so I’ve tried to engineer tests that at least approximate the spirit of the test. Many of the cards I tested performed far beyond what would have been required for the speed class markings they carried, while others fell far short of them. Others fell into a gray area, where they came close to the thresholds needed to qualify for one or more speed class markings, but technically fell short — and until such time as I’m able to test them properly, I’m willing to concede that they might have qualified for a particular speed class marking had they been tested under the right conditions. I’ll note these in my results.
Endurance
This one is pretty simple: how long will the card last if we write to every available byte on the card? Flash media has a tendency to degrade and become less reliable the more it’s written to, so I’m interested in seeing not only how many times we can write to the card before data errors start cropping up, but also how many times we can write to the card before it becomes completely unusable. I’m not sure there’s a standard here — at least, the SD specification doesn’t seem to define one — but I’ve seen things online indicating that 2,000 write cycles seems to be a reasonable expectation, so I’m going with that. Specifically, I want to see whether a card can reliably store data across at least 2,000 read/write cycles. Flash media isn’t perfect — some data errors are bound to occur even before the card has hit the 2,000 write cycle mark — so some allowance will be made for data errors that occur early on, as long as the error does not recur shortly afterwards.
Methodology
I had originally intended to use a combination of f3 and stressdisk to perform these tests; however, after finding some shortcomings to both tools, I decided to write a single tool that would combine the functionalities of both. I’ve made the source code available on GitHub.
Admittedly, these tests have not been completely scientific in nature, despite my desire to do so — for example:
- I’ve been making code fixes to my tool as the project has gone on, and different cards were tested by the different versions of the program (or multiple versions of the program).
- I’m using multiple different models/brands of SD card reader (although I’m in the process of trying to migrate to a single model).
- I’m using two different PCs that are running two different versions of Ubuntu.
But, the general strategy I took is described in the following sections.
All of these tests were run on x86_64 PCs running Ubuntu. SD cards are connected to SD card readers, which are attached to the system via USB. The device is opened with the O_DIRECT
and O_SYNC
flags to try to minimize the effects of caching by the system.
Authenticity
The logical space on the card (not including the Protected Area, if any) is divided into eight equal or near-equal segments. The length of each segment is determined by taking the total number of sectors on the card and dividing by eight. (Side note: Linux always considers a sector to be 512 bytes, regardless of the physical size of the sector on the device.) A starting sector is then chosen in each segment:
- In the first segment, the starting sector is always sector 0.
- In the last segment, a random starting sector is chosen such that is at most 8MB from the end of the device. (Note: for the purposes of this test, 1MB = 1,048,576 bytes.)
- In the remaining segments, a random starting sector is chosen that is at most 4MB from the end of the segment.
Next, nine blocks of random data, each 4MB in length, are generated and held in memory. (This number was chosen in the hopes that it would exceed the foreseeable write cache size of any SD card by at least a factor of 2.) Each block is written to the card, in a linear fashion, starting with each of the starting sectors chosen earlier. The final 4MB is written in a linear fashion starting 4MB from the end of the device’s logical address space. (Edit 3/13/2024: At some point I made a change so that the blocks are written in reverse order — e.g., starting with the last block and working back to the first. Within each block, however, data is still written sequentially from beginning to end.) Each block is then read back and compared to the data written. If all nine blocks match what was written to the card, the card is considered “genuine”; e.g., that its physical space matches (or possibly exceeds) the amount of space indicated in its CSD register. If the contents of the first block do not match what was written to the card, the card is considered unusable and testing stops completely. Otherwise, the card is considered “fake”. The logical space on the card is then bisected, 4MB of new random data is generated and written starting at the sector in the center of the new window, then read back and compared to the data written. This process is repeated until the extent of the card’s physical space has been determined.
I should note that my algorithm isn’t perfect — I’ve come across some fake flash that purported to be 512GB (but in actuality was closer to 32GB) that was misidentified as being closer to 256GB in size. In these situations, I’ve been allowing the first round of the endurance test to run on the device and using the results of that to determine where the card’s physical space ends.
Performance
The performance test is divided into two parts: a sequential I/O test and a random I/O test. Each of these parts is divided into a read test and a write test. The read test is performed first, followed by the write test. Data obtained from read operations is not checked for consistency. USB3-enabled readers are used to ensure that the speed of the USB bus is not a bottleneck.
During the sequential I/O tests, data is read from or written to the device continuously for 30 seconds. Data is read from or written to the device in chunks equal to the logical sector size (512 bytes) multiplied by the maximum number of sectors per request (as indicated by a BLKSECTGET
ioctl
call). After 30 seconds have passed, the total amount of data read or written is divided by the amount of time actually taken (measured with microsecond resolution) to determine the sequential data rate measurement.
During the random I/O tests, data is read from or written to the device continuously for 30 seconds. Each read or write operations is targeted to a random sector in the card’s physical storage space (as determined during the authenticity test). Data is read from or written to the device in 4KB chunks (as prescribed by section 4.16.2.4.2 of the SD Card Physical Layer Simplified Specification, version 9.0). After 30 seconds have passed, the total number of I/O operations is divided by the amount of time actually taken (measured with microsecond resolution) to determine the random IOPS measurement.
Again, these tests aren’t perfect. In fact, there’s a number of issues with them. For example:
- Most speed classes require you to issue a CMD20 command to the card to put it into an operating state where it will meet the demands of that speed class. Most USB card readers (including the ones I’m using) don’t provide a way to issue arbitrary commands to a card. The reader might be issuing this command to the card transparently to my application, or it might not be — I just don’t know.
- SD cards are divided into sections, called Application Units (or AUs). The Video Speed Classes in particular require certain commands to be issued to it to put the card into Video Speed Class mode and to specify which AU the host will be writing to. The host is then supposed to write only to that AU, in a sequential fashion (skipping over any blocks that are already in use). Once the host has reached the AU, it must issue another command to specify which AU it will be writing to next. Again, my card readers don’t provide a way for the host to issue these commands to the card, so my application isn’t doing this. Given the complexity involved in using Video Speed Class mode, I doubt that any of the card readers I’m using are doing this transparently for me.
- The Application Performance Classes require the card to be preconditioned in a certain way — e.g., you’re supposed to start by fully erasing the card, filling up 75% of it with data, then overwriting part of that data with 256MB of data (written in a sequential fashion). You’re then supposed to use that 256MB region for performing the actual performance tests. The test itself is supposed to last for 10 minutes. My application does not do this — primarily because, when I initially wrote the random I/O tests, I got my technical details from Wikipedia, which fails to mention any of these details. Additionally, the host is supposed to issue a number of commands to the card to perform the preconditioning — for example, CMD38 is to be used to perform a full erase of the card; CMD25 is to be used when filling up 75% of the card; and, if Application Performance Class 2 is being tested, CMD45/CMD46/CMD47/CMD48 are to be used to perform the actual reading/writing. Again, my card readers don’t provide a way to issue these commands to the card, so I have no way of doing this.
- In addition, read and write operations for the Application Performance Class tests are supposed to be 4KB-aligned. I didn’t fix this in my code until just now.
So I think I’m going to say that my tests encompass the spirit of each of the speed classes…but until I learn Verilog and can program an FPGA to perform a proper set of speed tests, my tests aren’t going to truly accurate.
Endurance
The physical space on the card’s user area (as determined during the authenticity test) is divided into 16 roughly equal segments — that is, the physical number of sectors is divided by 16 (rounding down), and each segment is assigned that number of sectors. The first segment begins at sector (physical_number_of_sectors / 16) * 0
, the second segment begins at (physical_number_of_sectors / 16) * 1
, the third segment begins at (physical_number_of_sectors / 16) * 2
, and so on. If the number of physical sectors on the card is not evenly divisible by 16, any extra sectors are assigned to the last segment. (I’ll note that while it’s possible for an SDSC card — that is, a card that is 2GB or less in size — to have a number of sectors that is not evenly divisible by 16, it’s not possible for an SDHC, SDXC, or SDUC card. This is because, for an SDHC, SDXC, or SDUC card, the card’s capacity [in bytes] is determined by taking the contents of the C_SIZE
field — from the card’s CSD register — and multiplying it by 512KB (or 524,288), which is itself a multiple of 16 sectors [or 8,192 bytes]. However, in practice, the authenticity test frequently finds fake flash whose physical number of sectors is not a multiple of 16.)
At the beginning of each round, the order of the segments is randomized. Then, for each segment (in the order they appear in the randomized list), a seed is determined, and a pseudorandom number generator is initialized with that seed. Pseudorandom data is then generated and written to the entire segment in a sequential fashion.
Once all segments have been written, the order of the segments is randomized again. Then, for each segment (in the order they appear in the randomized list), the pseudorandom number generator is re-initialized using the same seed that was used when the data was written to that segment. The pseudorandom data is regenerated; the data is read back from the card (again, in a sequential fashion) and compared to the pseudorandom data. If any discrepancies are found, the sector in which discrepancy appeared is flagged as “bad”. (The program continues to write to/read from sectors that have been flagged as “bad”, but does not take any further action if further discrepancies are found in those sectors.)
One all segments have been read back, the round is considered complete, and the program moves on to the next round.
If an I/O error occurs, the program has logic to detect whether the device has become disconnected from the system. If it has, it pauses, displays a message to the user, and waits for the device to be reconnected. If the disconnect occurred during a write operation, the segment in which the error occurred is restarted to avoid any corruption that may have occurred due to the contents of any write caches being lost at the time of the disconnect.
If it is determined that the device is still connected to the system, the program has logic to retry the I/O operation a set number of times. If all of those attempts fail, the program attempts to perform a reset operation on the card reader. Once the reset is complete, the program makes another set of attempts to retry the I/O operation. This process is repeated a set number of times, or until the I/O operation completes successfully. If all retry/reset attempts are exhausted, the program flags the sector in which the error occurred as “bad” and moves on to the next sector. (I’ll note that, at present, there is no distinction between a sector that has been flagged as “bad” due to a data discrepancy and a sector that has been flagged as “bad” due to a failed I/O operation; therefore, the program will still attempt to read and write to the sector on future rounds.)
This process repeats until any of the following conditions are met:
- An I/O error occurs, a reset operation is performed, and the reset attempt failed
- 50% or more of the sectors on the card have been flagged as “bad”
In the former case, there have been some instances where I’ve been able to “resurrect” the card and continue testing — generally by physically unplugging the card reader from the system and plugging it back in. If the card comes back to life through such a measure, I’ve generally allowed the endurance test to continue.
Card Readers Used
I’ve used the following card readers in my testing so far:
- SmartQ Single: A nice low-cost SD card reader that supports USB 3.0. However, in my testing, this reader has a tendency to stop responding after extended continuous use (generally once every few days). The reader has to be physically unplugged and reconnected to continue working.
- SmartQ Duo: Slightly more expensive than the SmartQ Single and sporting an almost identical form factor, it supports dual LUNs (meaning that it can operate on two cards simultaneously — one in the microSD slot, one in the full-size SD slot). It doesn’t seem to have the same problems with disconnects that the SmartQ Single does.
- SanDisk MobileMate: A compact reader that only accepts microSD cards. SanDisk has a technology that allows for faster transfer rates than is possible under the UHS-I protocol (up to 170MB/sec), and requires both a compatible card and a compatible reader to achieve. This reader supports these enhanced transfer rates.
- JJC CR-UTC4AC: A slightly larger, but still compact, SD/microSD card reader. This is a dual-LUN reader that supports UHS-II, and features USB-C, USB-A, and micro-USB connectors (although the micro-USB connector only supports USB 2.0). This has quickly become my reader of choice as it is only slightly more expensive than the SanDisk MobileMate while supporting UHS-II. I’ll note that some of these readers were sourced from Amazon Marketplace, while others were sourced from AliExpress; however, they are physically identical (at least on the exterior), and the product packaging was identical. I believe that there are no differences between the two.
- Lexar LRWM05U-7000: This is a compact UHS-II-compatible microSD reader that was bundled with the three Lexar Professional cards I purchased. It looks like Lexar doesn’t sell these by themselves.
- Prograde Digital Dual Slot Mobile Reader: A compact SD/microSD card reader with dual slots and dual LUNs that sports a USB-C connector and supports USB 3.2 and UHS-II. At some point I made the decision that I wanted to have at least one UHS-II-compatible card, and went in search of a good quality UHS-II-compatible card reader. This one initially appeared to be the best/cheapest option (until I later discovered the JJS CR-UTC4AC). I haven’t noticed any significant difference in performance between this one and any of the other readers I’m using. Its main downside is its USB-C connector — only because I only have a single USB-C port across the two machines that I’m presently using.
- Platinum PT-CRSA1: A more moderately-priced single LUN SD/microSD card reader. Honestly, I bought this one because I ran out of SD readers, and I happened to be at Best Buy at the time, and I wanted to see if they had anything comparable to what I had been using. This happened to be the cheapest USB 3.0-compatible card reader they had. I would say it’s been fine, but I won’t be buying any more of these — partly because the JJS CR-UTC4AC is a better value for slightly less money, but partly because Best Buy doesn’t carry them anymore.
- Togconn TOG-SD-CR: A nice low-cost multi-LUN card reader. This reader can read two SD cards, a Memory Stick, a CompactFlash card, and an xD card simultaneously. (This reader has two full-size SD card slots and two microSD card slots, but each full-size SD/microSD slot pair are a single LUN.) At one point, I was looking to see if there was a cost-effective way to test multiple cards at the same time. While there are readers out there that will read four SD cards simultaneously, they cost more than what I wanted to pay — so I settled on this one instead. Originally the plan was to use a microSD-to-Memory Stick adapter, a microSD-to-CompactFlash adapter, and a microSD-to-xD adapter to fill all of the available slots on this card reader; however, my results have been disappointing. While the microSD-to-CompactFlash reader is working well, I quickly noticed that a microSD card plugged into a microSD-to-Memory Stick adapter appeared to the reader as the wrong size. Reviews of microSD-to-xD adapters indicated poor results as well, so I opted not to even try. Consequently, I currently have two microSD cards plugged directly into this reader, with a third card plugged in using a QUMOX B664U microSD-to-CompactFlash adapter. (I’m not using the second port on the QUMOX, as that would cause it to RAID the two cards together — which I don’t want.)
- Realtek RTS5129: This card reader isn’t one I purchased directly; rather, it was built into one of the laptops that I used as one of my test rigs. Its primary advantage is that the Linux kernel module presents it as an SD/MMC reader (rather than a generic block storage device, as with all the other readers I’ve used). Since it’s wired up to the USB 2.0 bus internally, I didn’t use it for any performance testing; I only used it to read the contents of the various card registers for later analysis.
- ASUIZO CAZE: This is another dual LUN reader that I picked up from Indiegogo. It supports UHS-II and USB 3.1 gen 2, as well as providing rugged storage for multiple SD cards, SIM cards, and a SIM card removal tool.
Overall Scoring
As I was working on writing this, I realized that I needed a rating system for these cards. I was originally just looking at the top 10 in each of the three categories, but it became apparent that there were no crossovers between the top 10 in all three categories. There were a few that appeared in the top 10 in both the capacity and endurance categories — but it was only four of them, and two were from brands that were known to put out fake flash. That wasn’t ideal — so I decided to come up with a different system.
Here’s how it’s going to work:
- Each model will receive a separate score in each of the three categories (capacity, performance, and endurance). The total score for that model will be the average of the three scores.
- The score for the capacity test will be the distance, in standard deviations, of that model’s average skimp score from the average skimp score for all cards. Since we want to penalize fake flash and (to a lesser extent) skimpy flash, we’re going to negate the score — ergo, fake flash will generally have a negative score here, and genuine flash will generally have a positive score.
Let’s look at an example. Let’s say a card has a skimp score of 3.3%, the average is 14.29%, and the standard deviation is 31.33%. This would mean that the card’s skimp score is actually 0.35 standard deviations below average ((3.3 - 14.29) / 31.33 = -0.35
). We then negate this result, which would give us a score of +0.35.
This is going to penalize fake flash — and hard — and that’s kinda the idea. We don’t want to reward fake flash at all. - The score for the performance test will consist of four sub-scores, for each of the performance metrics (sequential read speed, sequential write speed, random read speed, random write speed), averaged together. As with the capacity test, we’ll use the distance, in standard deviations, from the average. Here, we want to reward faster-performing cards, so we’re not going to negate the scores like we did with the capacity score — the best-performing cards will generally have a positive score, while the worst-performing cards will generally have a negative score.
Let’s look at an example. Let’s say a card got 100MB/sec sequential read speeds, 50MB/sec sequential write speeds, 2,000 IOPS/sec random read speeds, and 250 IOPS/sec random write speeds. Now, let’s say the averages are 50MB/sec sequential read speeds, 25MB/sec sequential write speeds, 1,000 IOPS/sec random read speeds, and 350 IOPS/sec random write speeds. Finally, let’s say the standard deviations are 25MB/sec in sequential read speeds, 25MB/sec in sequential write speeds, 100 IOPS/sec random read speeds, and 50 IOPS/sec random write speeds. That would mean that the card scored 2 standard deviations above average in sequential read speeds ((100 - 50) / 25 = 2
), 0 standard deviations above average in sequential write speeds ((50 - 50) / 25 = 0
), 10 standard deviations above average in random read speeds ((2000 - 1000) / 100 = 10
), and 2 standard deviations below average in random write speeds ((250 - 35) / 50 = -2
). The individual scores for this card would be 2, 0, 10, and -2. We then take the four scores and average them together, giving it an overall performance score of 2.5 (( 2 + 0 + 10 + -2 ) / 4 = 2.5
). - The score for the endurance test will consists of six sub-scores: one for the number of read/write cycles the card endured before experiencing its first error, and one each for how many read/write cycles the card endured before 0.1%, 1%, 10%, 25%, and 50% of the sectors on the card have been marked as “bad”. If a card fails before reaching any of these thresholds, they will be considered to have instantly hit those thresholds. We want to reward cards that fail more slowly, so we’re going to take each threshold and subtract it from the previous one to figure out how many read/write cycles it went between hitting each one. For example, if a card hits the 1% threshold after 2,500 read/write cycles, and it hits the 10% threshold after 3,500 read/write cycles, then we’ll use the difference between the two — 1,000 in this example — as the basis for calculating the score. We’ll then figure out the distance, in standard deviations, from the average for each category, and finally we’ll average all six scores together.
Ok, that was a mouthful, so let’s look at an example. Let’s say a card experiences its first error at 1,000 read/write cycles, it hits the 0.1% threshold after 2,000 read/write cycles, the 1% threshold after 3,000 read/write cycles, the 10% threshold after 4,000 read/write cycles, the 25% threshold after 5,000 read/write cycles, and the 50% threshold after 6,000 read/write cycles. That means that we would use 1,000 as the basis for calculating each score.
Now, let’s say that the average for each category is 500, and the standard deviation is 250. A score of 1,000 would be two standard deviations above the average ((1000 - 500) / 250 = 2
), so the card would receive a score of 2 in each of the six categories. We then take the average of all six scores — which would be 2, so the card would receive a score of 2 for endurance.
This isn’t a perfect system — obviously, a card’s score is going to change whenever I test any other card — but it does give us something that lets us easily and objectively rate one card in comparison to the others. A perfectly average card will have a score of 0; a below average card will have a negative score; and an above average card will have a positive score.
Results
There’s a number of ways I could break down this data. Since I did define some goals for this project, let’s go in order of those goals.
Capacity
As I said earlier, I wanted to identify whether these cards really offered the capacity that they advertised. For this result, I created a metric called “skimp” — which I’m defining as:
S = 1 – (CPhysical/CPackage)
Where CPhysical is the card’s physical capacity, CPackage is the capacity advertised on the package (or in some cases, on the exterior of the card or on the product listing for the card), and S is the skimp factor, expressed as a percentage. Think of it like the answer to the question of “how much capacity am I losing because the actual physical capacity of the card is lower than what’s advertised on the package?” Lower numbers (or even negative numbers) are better. For example, if a card is advertised as being 8GB in size, and the physical storage capacity is 7.8GB, then it would have a skimp factor of 2.5%, because you lost 2.5% of the stated capacity of the card. On the other hand, if a card is advertised as being 8GB in size, and it turns out to actually be 8.2GB in size, then it would have a skimp factor of -2.5%. I used linear scaling for data storage prefixes (e.g., one kilobyte = 1,000 bytes, one megabyte = 1,000 kilobytes, etc.), because if I had used binary scaling, no card would have had a skimp level anywhere close to 0.
So…is there a difference between the cards I got from Amazon vs. the cards I got from AliExpress?
(Error bars represent the range of values obtained.)
At first glance, it would look like the AliExpress cards were a lot more skimpy — and they were — but there’s a reason for this: I only ordered authentic cards from Amazon, whereas I ordered a mix of authentic and fake cards from AliExpress.
What if we narrow down the data to just the authentic cards from both marketplaces?
Well, the margin is a little closer here, but the AliExpress cards were still skimpier. Why is that? Let’s break this down further: both by which marketplace I obtained them from, and by brand/model. (Note that I’m adding the off-brand/knockoffs back in — just so that I don’t have to make another chart later that has all the cards.)
(Side note: I like making rainbows.)
Admittedly it’s kinda hard to tell with this chart — because it includes the fake cards, and the chart has to scale to show those — but aside from the Kingston Canvas Select Plus’s, all of the Amazon cards had a skimp factor of 0.65% or less, whereas the AliExpress cards — even the name-brand ones — were all over the place (with the Kioxia Exceria Plus 32GB being the worst non-fake flash offender, coming in at a skimp factor of 3.32%).
From this data, I think we can draw a couple of conclusions:
- Authentic cards generally have a skimp factor of 5% or less.
- Fake cards generally have a skimp factor of 50% or more.
Is it possible for a card to be fake and have a skimp factor of less than 50%? Sure — but in practicality, it doesn’t seem to happen. I think it’s more practical for fake flash sellers to scale up the logical storage space by a factor of 2 or more. (Edit: OK, the QWQ Extreme Pro proved me wrong here.)
By that same token, is it possible for an authentic card to have a skimp factor of more than 5%? Sure — I just didn’t find any examples of this happening.
We can also pick out the top 10 performers in this category:
- Auotkn Extreme 8GB
- QEEDNS 8GB
- Kingston Industrial 8GB
- Bekit 8GB
- Lexar Professional 1000x 64GB
- Samsung EVO Plus 64GB
- Samsung PRO Endurance 32GB
- Samsung EVO Plus 32GB
- SanDisk Ultra 128GB
- Hiksemi NEO 8GB
(Note: The charts above are being automatically rendered using data from my spreadsheet — so it’s possible that the charts above indicate a different top 10, and I just haven’t updated the list above. The list here is current as of 6/14/2024.)
Here’s how these cards lined up on my rating scale:
We can also look at these cards from another angle: price per gigabyte:
Here, we can see that the AliExpress cards had a little bit of an advantage. Here’s how it shook out for all of the cards I’ve tested so far:
Here, the Netac 64GB is the winner.
June 14, 2024
Performance
The second goal of this project was to look at performance — so let’s compare how the Amazon cards performed when compared to the AliExpress cards.
(Error bars represent the range of values obtained.)
At first glance, it would appear that there’s a marked difference between the Amazon cards and the AliExpress cards — with Amazon cards performing better than the AliExpress cards across the board and with less variability in scores across Amazon cards vs. AliExpress cards. Again, however, I obtained mostly name-brand cards from Amazon, whereas I got a mix of name-brand, off-brand, and knock-off cards from AliExpress. What if we separate the AliExpress cards out into name-brand cards, off-brand cards (fake and authentic), and knockoff cards (fake and authentic)?
Well…it still looks like the Amazon cards did better than the name-brand cards I got from AliExpress.
But it also highlights a couple more important differences:
- Categorically, off-brand cards did worse than name-brand cards in all performance metrics.
- Categorically, knockoff cards did worse than off-brand cards, and much worse than name-brand cards, in all performance metrics. (Yes, most of the fake cards I tested got less than 10 write operations per second on the random write test. Yes, some of them got less than one write operation per second. I don’t know how they managed to suck so bad…but they found a way.)
Ok, let’s spin this a different way: which cards performed the best? First, let’s look at the individual scores in each category:
Now, how did these cards score according to my ratings system?
The graphs in this section are all dynamically generated from my data — so the top 10 may change at any point. But as of this writing, the top 10 would be:
- Kingston Canvas Go! Plus 64GB
- PNY Premier-X 128GB
- SanDisk Extreme 64GB
- HP MicroSDXC mx330 64GB
- Kioxia Exceria G2 64GB
- Kingston Industrial 8GB
- Samsung EVO Plus 64GB
- PNY Elite-X 64GB
- SanDisk Ultra 128GB
- SanDisk Extreme 32GB
We can also look at this a different way: which cards would work best in certain applications?
When using a microSD card in a digital camera, sequential write speeds are generally going to be the most important. When taking still photographs, the camera must generally be able to write the picture out to the card before it can take the next one (although most cameras can usually store a certain amount of data in RAM to allow for bursts) — so faster write speeds means the camera can be ready to take the next picture sooner. When shooting video, the camera has to be able to write data out to the card faster than the camera can generate it — if it can’t, it generally has to stop recording video. Sequential read speeds are important as well, as you generally want to be able to offload pictures and videos — to, say, your computer — very quickly.
The nice thing about this ratings system is that I can very easily re-weight certain categories. So for this rating, let’s give the sequential write speed double weight, and random I/O scores half weight:
So, for photography/videography, my top picks here would be:
- Kingston Canvas Go! Plus 64GB
- SanDisk Extreme 64GB
- PNY Premier-X 128GB
- Kioxia Exceria G2 64GB
- HP MicroSDXC mx330 64GB
- SanDisk Extreme 32GB
- Kingston Industrial 8GB
- SanDisk Extreme PRO 64GB
- SanDisk Extreme PRO 32GB
- Hiksemi NEO 128GB
The other way we could look at it is in something like a tablet, mobile phone, or mobile game console (like a Nintendo Switch or a Steam Deck). Here, random read speeds are going to be most important — as you want your apps/games to load quickly. Sequential write speeds are going to be a factor as well — as that’s going to affect how quickly you can download new apps and games.
So let’s re-weight these cards — we’ll give random read speeds double weight, and we’ll give random write and sequential read speeds half weight:
So, the top picks here would be:
- Kingston Canvas Go! Plus 64GB
- SanDisk Extreme 64GB
- PNY Premier-X 128GB
- Kioxia Exceria G2 64GB
- HP MicroSDXC mx330 64GB
- Samsung PRO Endurance 32GB
- Samsung EVO Plus 64GB
- SanDisk Ultra 32GB
- SanDisk Extreme 32GB
- Kingston Industrial 8GB
(Note: I’ve removed the Lexar Professional 1000x 64GB from all of the top 10’s. After the issues that I experienced with them, I just can’t recommend that anyone buy them. See the discussion on that card for more details.)
There are several here that appear on all three lists, and I think I’m going to declare them to be “all-around good performance cards”:
- Kingston Canvas Go! Plus 64GB
- PNY Premier-X 128GB
- SanDisk Extreme 64GB
- HP MicroSDXC mx330 64GB
- Kioxia Exceria G2 64GB
- Kingston Industrial 8GB
- SanDisk Extreme 32GB
June 17, 2024
Endurance
This is an area where it’s going to take a while to get conclusive results. It takes time to test these cards, and some of them last longer than others. Take the Hiksemi NEO 8GB, for example: sample #1 has been going nearly non-stop for the last 11 months, has completed over 50,000 read/write cycles, and hasn’t experienced a single error so far. Its small capacity (relatively speaking) is one of the main reasons it’s been able to complete so many read/write cycles — it has averaged about 178 read/write cycles completed per day. Compare this to sample #2 of the Kingston Canvas Select Plus 32GB — which performed similarly in performance tests — which is only averaging about 24 read/write cycles per day. Larger cards are moving even more slowly: for example, the three Hiksemi NEO 128GB samples have averaged between 4.3 and 8.2 read/write cycles per day. At these rates, it takes between 8 and 15 months to test a card to 2,000 read/write cycles — not to mention how long it would take a particularly reliable card to be tested to the point of failure.
Nevertheless, after a year of testing, I’ve obtained a fair amount of data, and I think it’s worth sharing.
So…let’s go over some high-level findings.
Time to First Error
Time to first error is the number of read/write cycles completed, without errors, before the card encounters its first error. In this context, “errors” includes unrecoverable I/O errors, data mismatches between what was written to the card and what was read back, and other failures that cause the card to become unusable. Note that cards that have not yet experienced their first error are not included in these figures unless otherwise noted.
In this area:
- The average number of read/write cycles completed before first error, for all cards, was 2,316, with a median value of 955 (n=145, min=0, max=20,876).
- In terms of percentiles:
- 99th percentile was 18,914 read/write cycles. (For those of you not familiar with how percentiles work: this means that 99% of cards will experience their first error before completing 18,914 read/write cycles.)
- 95th percentile was 9,229 read/write cycles.
- 90th percentile was 5,907 read/write cycles.
- 75th percentile was 2,314 read/write cycles.
- 50th percentile was 955 read/write cycles.
- 25th percentile was 203 read/write cycles.
- 10th percentile was 5 read/write cycles.
- 5th percentile was 0 read/write cycles.
- 1st percentile was 0 read/write cycles.
- Name-brand cards obtained from Amazon performed markedly better than name-brand cards obtained from AliExpress. The average for name-brand cards from Amazon was 3,300 read/write cycles, with a median value of 1,415 (n=36, min=0, max=20,876); for name-brand cards from AliExpress, the average was 1,357 read/write cycles, with a median value of 826 (n=36, min=0, max=6,356).
- Name-brand cards performed similarly to off-brand cards (not including fake flash cards). The average number of read/write cycles for name-brand cards was 2,567 read/write cycles, with a median value of 1,366 (n=67, min=0, max=20,876); while the average for off-brand cards was 2,437 with a median value of 1,323 (n=61, min=0, max=15,934). If you’ve been watching this page, you should note that this is a reversal from how I had reported this result previously: in the past, name-brand cards had performed markedly worse than off-brand cards. However, as time has gone on and I’ve obtained more data, name-brand cards have closed the gap.
- Unsurprisingly, fake flash performed significantly worse than authentic flash. The average for fake flash was 1,029 read/write cycles before first error, with a median value of just 377 (n=25, min=0, max=9,336); for authentic cards, the average was 2,584, with a median value of 1,434 (n=120).
- Among name brands, SanDisk performed the best — they averaged 4,800 read/write cycles before encountering their first error, with a median value of 1,970 (n=20, min=70, max=20,876). Lenovo was the worst performer, completing an average of 291 read/write cycles before encountering their first error (n=3).
- I had previously reported that SanDisk’s top spot was due in large part to how well one of their Industrial cards had performed. However, even with all industrial-grade cards removed from the dataset, SanDisk still maintains the top spot — averaging 2,207 read/write cycles completed before encountering their first error. The next closest competitor would be Kioxia, at an average of 2,166 read/write cycles completed before encountering their first error.
- Among off-brand cards (not including fake flash cards), Microdrive performed the best, completing — on average — 7,333 read/write cycles before encountering their first error, with a median value of 6,973 (n=3, min=4,270, max=10,757). XrayDisk was the worst performer, completing — on average — just 27 read/write cycles before encountering their first error, with a median value of 12 (n=3, min=2, max=67).
- Once again, there are some cards that have performed exceptionally well, but are not included here because they have not encountered their first error. If all of these cards experienced their first error now, Hiksemi would become the top performer.
The graph below shows the distribution of the number of read/write cycles completed before first error for all cards.
The table below shows percentile rankings for the various categories of cards.
All cards | Amazon cards | AliExpress cards | Name-brand cards | Off-brand cards* | Authentic flash | Fake flash | |
---|---|---|---|---|---|---|---|
n | 145 | 31 | 111 | 67 | 52 | 120 | 25 |
99pth | 18,914 | 20,538 | 13,565 | 20,132 | 14,803 | 19,388 | 8,440 |
95pth | 9,229 | 18,800 | 7,457 | 8,790 | 11,183 | 10,810 | 4,875 |
90pth | 5,907 | 5,401 | 5,109 | 5,783 | 6,801 | 6,357 | 1,834 |
75pth | 2,314 | 2,301 | 2,156 | 2,444 | 3,013 | 2,608 | 662 |
50pth | 955 | 1,415 | 728 | 1,366 | 1,522 | 1,434 | 377 |
25pth | 203 | 534 | 115 | 353 | 203 | 298 | 23 |
10pth | 5 | 159 | 4 | 100 | 5 | 12 | 2 |
5pth | 0 | 63 | 0 | 2 | 1 | 0 | 0 |
1pth | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
* Not including fake flash.
September 9, 2024 (graph updates automatically)
Time to 0.1% Failure
It should be noted that a number of cards suffered errors early on, but many times those errors tended to be minor — affecting perhaps only a handful of sectors, and not recurring for some time. I’m not sure if these errors are being caused by the cards, or if some other factor is involved — such as issues with saturation of the USB bus, issues with the readers, issues with the Linux kernel, or other issues. Perhaps these issues wouldn’t come up in real-world use. It’s also possible that these errors might arise during normal use, but would go unnoticed by the user because they occurred so infrequently or affected files that would never be used (such as log files that get automatically overwritten).
It might be more useful to examine the time to 0.1% failure — that is, the number of read/write cycles a card can complete before 0.1% of the sectors on the card have experienced errors. By the time a card reaches this point, a user would likely start to notice corruption in their files and/or filesystem corruption and would begin to suspect that the card had gone bad.
In this area, I have fewer samples to report on so far. However, here is what I have so far. Again, note that these figures only include cards that have reached a 0.1% failure rate unless otherwise noted:
- The average time to 0.1% failure, for all cards, was 3,664, with a median value of 1,851 (n=68, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAliExpress=60, nAmazon=8).
- The data so far consists primarily of off-brand cards (nNameBrand=14, nOffBrand=29, nKnockoff=17).
- The data so far consists of mostly authentic flash (nAuthentic=44, nFake=24).
- Unsurprisingly, fake flash compared significantly worse than authentic flash.
- The average time to 0.1% failure for authentic flash was 4,995 read/write cycles, with a median value of 3,141 (n=44, min=0, max=20,876).
- The average time to 0.1% failure for fake flash was 1,167 read/write cycles, with a median value of 632 (n=24, min=0, max=10,541).
- If all cards that have not yet reached 0.1% failure were to reach it now:
- Between cards sourced from AliExpress vs. Amazon, the data would skew in favor of cards sourced from Amazon (but not by much). This holds true even if you only compare name-brand cards sourced from AliExpress to name-brand cards sourced from Amazon.
- Between name-brand cards, off-brand authentic cards, and fake flash cards, the data would skew in favor of off-brand cards.
The graph below shows the distribution of the number of read/write cycles completed before reaching 0.1% failure for all cards.
September 15, 2024 (graph updates automatically)
Time to 1% Failure
By the time a card reaches a 1% failure rate, the user would likely notice major issues with the card — filesystem structures would likely be corrupted, files would likely be corrupted, and there’s a good chance that the card would have to be reformatted — resulting in data loss — in order to become usable again.
This measure is slightly less useful than the previous two measures; however, there are some use cases where it might still be useful — for example, when considering a card that is going to be used in a device where data will be continuously overwritten and rarely read, such as a dashcam or security camera, In this type of situation, the user may not notice any issues until it affects filesystem structures, causing the device to exhibit errors when it tries to read those structures from the card. The “time to 0.1% failure” measure may be useful for determining when it’s time to replace the card, while this measure may be more useful for determining when the card has reached the end of its useful lifespan.
In this area:
- The average time to 1% failure, for all cards, was 3,119 read/write cycles, with a median value of 1,753 read/write cycles (n=40, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=4, nAliExpress=36).
- The data so far consists of mostly off-brand cards (nNameBrand=5, nOffBrand=23, nKnockoff=12).
- The data so far consists mostly of authentic flash (nAuthentic=23, nFake=17).
- As before, fake flash compared significantly worse than authentic flash.
- The average number of read/write cycles endured before reaching 1% failure for fake flash was 2,221, with a median value of just 730.
- The average number of read/write cycles endured before reaching 1% failure for authentic flash was 4,668, with a median value of 2,209.
- As before, fake flash compared significantly worse than authentic flash.
- This data only includes cards who have reached the 1% failure threshold, as well as those cards that have experienced errors that rendered the card inoperable. If all other cards currently being tested were to hit the 1% failure threshold right now:
- Between cards sourced from AliExpress vs. AliExpress, the data would skew in favor of cards sourced from Amazon. However, this could be attributed to the fact that the Amazon cards have been in testing for longer than the AliExpress cards (on average).
- Between name-brand cards, off-brand authentic cards, and fake flash, the data would skew in favor of off-brand cards.
- I’ll note that of the 40 cards represented here, over half of them never actually made it to the 1% error threshold — they experienced some sort of error rendering them inoperable before reaching this point.
The graph below shows the distribution of the number of read/write cycles completed before reaching 1% failure.
June 12, 2024 (graph updates automatically)
Time to 10% Failure
By the time a card reaches 10% failure, the card is likely to be completely unusable. Files and filesystem structures are likely to be corrupted, rendering most data unusable and only partially recoverable. I don’t think there’s much of a use case here for not noticing issues with a card before it reaches the 10% failure threshold, so these statistics are primarily for curiosity more than anything.
In this area:
- The average time to 10% failure, for all cards, was 3,237 read/write cycles, with a median value of 1,850 (n=37, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=4, nAliExpress=33).
- The data so far consists of mostly off-brand cards (nNameBrand=5, nOffBrand=21, nKnockoff=11).
- The data so far consists of mostly authentic flash (nAuthentic=22, nFake=15).
- Once again, fake flash fared significantly worse than authentic flash.
- The average number of read/write cycles completed before reaching the 10% failure threshold for fake flash was 1,928, with a median value of 768.
- The average number of read/write cycles completed before reaching the 10% failure threshold for authentic flash was 4,617, with a median value of 2,389.
- Once again, fake flash fared significantly worse than authentic flash.
- This data only includes cards that have reached the 10% failure threshold, as well as those cards that have experienced errors that have rendered the card inoperable. If all other cards currently being tested were to reach the 10% failure threshold now:
- Between cards sourced from Amazon vs. AliExpress, the data would skew slightly in favor of Amazon cards. Once again, however, this could be attributed to the fact that the Amazon cards have been in testing for longer, on average, than the AliExpress cards.
- Between name-brand cards, off-brand authentic cards, and fake flash cards, the data would skew in favor of off-brand authentic cards.
- I’ll note that most cards never actually made it to the 10% failure threshold. Of the 37 cards represented here, 24 experienced an error rendering them inoperable before reaching the 10% failure threshold.
The graph below shows the distribution of the number of read/write cycles completed before reaching 10% failure.
June 12, 2024 (graph updates automatically)
Time to 25% Failure
By the time a card reaches the 25% failure threshold, it’s extremely likely that the card will be completely unusable. Once again, I can’t think of a use case where someone would allow a card to continue operating until it reaches this point, so these numbers are purely for curiosity.
In this area:
- The average time to 25% failure, for all cards, was 3,277 read/write cycles, with a median value of 1,990 (n=35, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=4, nAliExpress=31).
- The data so far consists mostly of off-brand cards (nNameBrand=5, nOffBrand=19, nKnockoff=11).
- The data so far consists mostly of authentic flash (nAuthentic=20, nFake=15).
- Once again, fake flash fared significantly worse than authentic flash here.
- The average number of read/write cycles completed before reaching the 25% failure threshold for fake flash was 2,001, with a median value of 927.
- The average number of read/write cycles completed before reaching the 25% failure threshold for authentic flash was 4,926, with a median value of 2,389.
- Once again, fake flash fared significantly worse than authentic flash here.
- The data only includes cards that have reached the 25% failure threshold, as well as cards that have experienced an error that has rendered them inoperable. If all other cards were to reach the 25% failure threshold now:
- Between cards sourced from Amazon vs. AliExpress, the data would skew in favor of Amazon cards. Once again, however, this could be explained by the fact that, on average, Amazon cards have been in testing for longer and have had more time to accumulate more read/write cycles than the AliExpress cards.
- Between name-brand cards, off-brand authentic cards, and fake flash cards, the data would skew in favor of off-brand cards.
- I’ll note that most cards never made it to the 25% failure threshold. Of the 35 cards represented here, 24 of them experienced an error rendering them inoperable before reaching the 25% failure threshold.
The graph below shows the distribution of the number of read/write cycles completed before reaching 25% failure.
June 12, 2024 (graph updates automatically)
Time to Complete Failure
In my testing, I consider a card to be completely failed when either (a) it encounters an issue that renders the card inoperable, or (b) 50% or more of the sectors on the card have experienced errors. The former is a more useful metric; the latter is primarily just for funsies.
In this area:
- The average time to complete failure was 3,714 read/write cycles, with a median value of 1,990 (n=35, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=4, nAliExpress=31).
- The data so far consists mostly of off-brand cards (nNameBrand=5, nOffBrand=19, nKnockoff=11).
- The data so far consists mostly of authentic flash (nAuthentic=20, nFake=15).
- Once again, fake flash fared significantly worse than authentic flash.
- The average number of read/write cycles to complete failure for authentic flash was 4,941, with a median value of 2,424.
- The average number of read/write cycles to complete failure for fake flash was 2,078, with a median value of 981.
- Once again, fake flash fared significantly worse than authentic flash.
- The data here only includes cards that have reached the 50% error threshold, as well as cards that have experienced an error rendering them inoperable. If all other cards currently being tested were to fail right now:
- Between cards sourced from Amazon vs. AliExpress, the data would skew in favor of cards sourced from Amazon. Again, however, this could be explained by the fact that the Amazon cards have been in testing for longer and have had more time to accumulate more read/write cycles than the AliExpress cards.
- Between name-brand cards and off-brand cards, the data would skew in favor of off-brand cards. Again, however, this could be explained by the fact that the off-brand cards have been in testing for longer and have had more time to accumulate more read/write cycles than the name-brand cards.
- I’ll note that most cards never made it to the 50% failure threshold. Of the 35 cards represented here, 24 of them experienced an error rendering them inoperable before reaching the 50% failure threshold.
The graph below shows the distribution of the number of read/write cycles completed before completely failing.
June 12, 2024 (graph updates automatically)
Known Failure Modes
There were a number of ways in which I observed cards failing. I’m lumping them into two categories: data verification errors, and card failures. The “data verification errors” category consists of bit flip errors, data shift errors, missing data errors, write failure errors, and corrupted data errors. The “card failures” category consists of unresponsive cards, corrupted CSDs, and write-protected cards.
Bit Flip Errors
The term “bit flip errors” refers to a phenomenon when the data read back matches the data written to the card, with the exception of a few bits — or sometimes only one bit. Bit flip errors can occur when a bit flips from a 0 to a 1, or from a 1 to a 0. Bit flip errors tended to happen most frequently on fake flash and low-quality flash, and once they started, they tended to increase in number and frequency as time went on.
Address Decoding Errros
Address decoding errors refers to a situation where the card returns incorrect data due to addressing the wrong portion of flash memory. It’s not known whether these errors are occurring when reading or writing the data, but I assume it can happen on either one. This phenomenon affects a variable number of sectors at a time; however, most times the number of sectors is in the single-digits, and most commonly (but not always) the data is offset by two sectors (forward) from where it should have been.
It took me some time to notice this phenomenon occurring; however, once I did, I started noticing it happening more and more. It doesn’t seem to be isolated to any particular brand of card, any particular card reader, or any particular host machine. It’s frankly baffling the hell out of me, because I don’t know if it’s just something wrong with the cards or if it’s something else. However, this tended to be a pretty common failure mode for name-brand cards.
Missing Data Errors
I’m using the term “missing data error” to refer to a situation where a card responded to a read request, but the data returned consists of a single byte repeated over and over (usually 00
or ff
). This type of error tends to occur with fake flash when reading from a sector that isn’t mapped to a physical sector in the card’s flash storage.
Write Failure Errors
I have observed instances where the data read back from the card was actually written during a previous round of testing. I’m using the term “write failure” to refer to this type of error. Given that the data that was read back frequently originated from a completely different sector from where it was originally written to, I think it’s reasonable to surmise that this is a failure in the card’s wear leveling algorithm, and that one of two things happened:
- The original data was committed to the card, but the wear leveling algorithm failed to correctly store the location of the data in its block map; or
- The wear leveling algorithm correctly updated its block map; however, it failed to write the original data to the card, and thus the data that was read back was the data that was in that block previously.
Corrupted Data Errors
I’m using the term “corrupted data errors” to refer to any other situation where a card responded to a read request, but the data returned did not match the data written. Sometimes this can be due to a write request that was cached by the card but not written out (or only partially written out) to the card’s flash storage. In general, though, I’m using this term to refer to a data verification error that doesn’t fit into any of the other categories.
Unresponsive Cards
I’m using the term “unresponsive card” to refer to a situation where the system did not expose the card as a block device when plugged into a card reader.
Upon further inspection, I managed to get a little more insight as to what’s happening with at least some of these cards. When initializing a card, the host is supposed to send ACMD41 to the card to tell it to begin its power-up sequence. While the power-up sequence is taking place, the host can issue additional ACMD41s to the card to ask the card whether it has finished powering up. From the time the card gets the first ACMD41, it has one second to complete its power-up sequence. With at least a few cards, I could see it responding to the ACMD41s commands, but they would never indicate that their power-up sequence was complete.
I was able to unintentionally trigger this scenario with a working card while working on an FPGA design — and after diagnosing the issue for some time, I concluded that the issue was that the card was being undervolted. This leads me to conclude that the “dead” cards have some component (like a resistor, transistor, diode, etc.) that has failed, and is either preventing the card from getting up to operating voltage or is preventing it from detecting that it got up to operating voltage.
Corrupted CSD
The CSD register is a register that the host can read from the card, and specifies a number of parameters for the card — such as whether the card is write protected, how much time it should take for a nominal write operation to complete, and — most importantly — the size of the card. There have been two instances (with a single brand of card) where the contents of the card’s CSD register changed, which resulted in the overall capacity of the card changing to be far less than what it was originally. When this has happened, I’ve immediately declared the card “dead” without any further testing.
Write-Protected Cards
Some cards have been known to make themselves write-protected — either by indicating as such in the CSD register or by exhibiting I/O errors whenever writes are attempted. It is not known whether this behavior is accidental or by design. If this behavior is by design, a hypothetical design might be as follows:
- A card has a certain number of “spare” sectors. These sectors are designated for performing wear leveling and/or bad sector replacement.
- The card maintains a sector map, for its internal use, that maps logical sectors to physical ones. When the host requests a given sector, it uses this map to determine the physical location of the requested sector in the flash core.
- As wear leveling is performed, the sector map is updated to reflect the physical location of each logical sector in the card’s user area.
- If a bad sector is detected, it is flagged as such in the sector map and replaced with one of the spare sectors — thus reducing the number of spare sectors available.
- Once the card runs out of spare sectors (or falls below a defined threshold), it makes itself read-only to protect the integrity of the data already on the card.
Of course, the other explanation is that this behavior is accidental — for example, the portion of flash memory where the card stores its write-protect flags could become corrupted, causing it to report that it is write protected.
Regardless of the mechanism, when this situation occurs, I’ve generally tried to reset the card — by pulling it from the reader and reinserting it — to try to resolve the situation. (After all, there is a “write protect until power cycle” flag in the Physical Layer Specification.) If that fails to fix it, I’ve declared the card “dead”.
Device Mangling
I’ve noted a few instances now where a read request for one device seemingly returns data from another device. I’m referring to this type of error as a “device mangling error”. It’s entirely plausible that some of the errors that I previously classified as address decoding errors or corrupted data errors were actually device mangling errors.
Overall Picks
To get a list of top performers, I’m going to look primarily at the top scores in the capacity and performance categories. For now, I’m not going to include any of the endurance data in here, as I still have incomplete data for all but a handful of cards.
Note: This list is subject to change at any time!
#1: Kingston Canvas Go! Plus 64GB The Kingston Canvas Go! Plus is the middle of Kingston’s current consumer offerings, between the Canvas Select Plus and the Canvas React Plus. Kingston is definitely pushing the limits of performance here: this card boasts read speeds of up to 170MB/sec, and in my testing, it delivered. You’ll need a compatible reader to take advantage of those speeds — but even if you don’t have one, you’ll still get exceptional performance out of it. This makes it an excellent choice for all applications, from gaming consoles to high-speed photography to high definition video recording. Skimp is a factor to consider, however: while this card is advertised as 64GB, the actual amount of usable space is closer to 62.2GB.Available from: AliExpress, Amazon, Kingston, and many others |
#2: SanDisk Extreme 64GB The SanDisk Extreme is the middle of SanDisk’s consumer offerings — between the Ultra and the Extreme PRO. Sadly, I just couldn’t get the Extreme PRO to give the speeds that it advertises on the package — but with the right reader, the Extreme had no problem getting close to the advertised read speeds of 170MB/sec. Even without a compatible reader, this card still gets good sequential read speeds and excellent sequential write and random read speeds, making it an excellent fit for write-intensive applications, such as high definition video recording, or read-intensive applications such as portable gaming consoles.Available from: AliExpress, Amazon, Western Digital, and many others |
#3: PNY Premier-X 128GB The PNY Premier-X 128GB is the mid-high offering in PNY’s admittedly confusing lineup. While it wasn’t able to perform quite as well as the Kingston Canvas Go! Plus, it did still offer excellent performance across the board, and you won’t need a specialized device to be able to take advantage of it. This makes it ideal for a wide variety of applications. This card was somewhat skimpy, however: while this card is advertised as being 128GB, the actual amount of usable space is closer to 124.7GB.Available from: Amazon |
#4: HP microSDXC mx330 64GB First things first: don’t buy the 128GB version — it’s trash. The 64GB version, however, offers decent performance across the board, but exceptionally high random write speeds. This makes it a good fit for applications such as gaming consoles, smartphones, and embedded systems like the Raspberry Pi, where the underlying operating system might write to many different files in a short amount of time. Skimp is a factor to consider here: while this card is advertised as being 64GB, the amount of usable space is closer to 62.2GB.Available from: AliExpress |
#5: Kioxia Exceria G2 64GB The Kioxia Exceria G2 is an improved version of the original Kioxia Exceria. In my tests, it did better than average across all performance metrics, and did exceedingly well for write speeds — making it an excellent fit for write-intensive applications, such as high definition video recording and embedded systems like a Raspberry Pi. The only downside is skimp, with Kioxia being one of the worst offenders: a 64GB card only gives about 61.9GB of usable space.Available from: AliExpress |
#6: Kingston Industrial 8GB The Kingston Industrial is Kingston’s high-reliability offering — the fact that it performed so strongly is simply a bonus. While it delivers above average performance across the board, write speeds were its strength. This makes it an excellent fit for write-intensive applications where reliability is a must, such as DVRs for security cameras. As a bonus, this card wasn’t skimpy: it’s advertised as being 8GB in size, and the amount of usable space comes in at around 8.04GB. All of this comes at a price, however; and that price is…well…price: this card had the highest price per gigabyte of any card that I tested.Available from: Amazon, Mouser Electronics, Kingston |
#7: Samsung EVO Plus 64GB Samsung has released an updated version of its EVO Plus line of microSD cards. Make sure to get the white and blue version (like is pictured at left)! This version features sequential read speeds that are about 1.5x faster than the previous version, and random read speeds that about 1.75x faster, but write speeds that are a bit below average. This makes it an excellent fit for gaming consoles — where fast read speeds mean reduced loading times — but not as good for high definition video. In addition, Samsung was one of the best brands when it comes to skimp: a 64GB card actually provides about 64.09GB of usable space.Available from: AliExpress, Amazon, Samsung, and others |
#8: SanDisk Ultra 128GB The SanDisk Ultra is SanDisk’s low-end consumer offering. Despite this, this card managed to get ridiculously high sequential read speeds, which were somewhere in between the Kingston Canvas Go! Plus and the Samsung EVO Plus 64GB — but it will require a device that can support these higher speeds. It suffers in write speeds, however — so while it would be good for ensuring fast load times in something like a gaming console, expect download speeds to be limited by how fast it can write to the card.Available from: AliExpress, Amazon, SanDisk, and many others |
#9: SanDisk Extreme 32GB There seem to be multiple versions of the SanDisk Extreme 32GB floating around out there — with SanDisk making the switch sometime between April 2020 and September 2023. Both versions have excellent sequential write speeds, while the newer version has enhanced sequential read speeds and random read speeds (if you have a device that can support the enhanced speeds). This makes it a good fit for high definition video recording, while still being a decent fit for powering a gaming console.Available from: AliExpress, Amazon, Western Digital, and many others |
#10: PNY Elite-X 64GB The PNY Elite-X seems to be the mid-range offering in PNY’s — again, admittedly confusing — lineup. While it does offer above-average performance across the board, its strength here is random write speeds. This makes it a good choice for data logging devices, smartphones, or embedded systems like the Raspberry Pi, where the underlying operating system might try to write to many non-sequential locations in a short amount of time. Skimp is a factor to consider, however: while this card is advertised as 64GB, the amount of usable space ends up being closer to 62.2GB.Available from: Amazon |
Here’s how the actual scores shook out:
This lines up pretty well with the results that I’ve been seeing — so maybe my rating system isn’t so bad after all.
June 14, 2024
Individual Cards
Below are the results that I’ve gotten from each brand/model of card — in alphabetical order by brand/model/capacity — along with a discussion indicating why I chose this card, things that I found out about the cards, things that happened during testing, etc. A few things to note as you peruse this list:
- Prices paid are shown in US Dollars.
- Prices paid include shipping to the United States. In instances where I ordered multiple items from the same seller, I’ve divided the shipping amount by the number of items I purchased to determine a per-item shipping price.
- Priced paid do not include sales tax — as sales tax in the US varies widely depending on where you live.
- The data is organized by brand name. If all of the cards underneath that brand name have the same value for one of their attributes, I’ll list it in the bulleted list. Otherwise, I’ll list it in the table. (For example, if I obtained three of a particular brand, and I paid the same price for all three of them, I’ll list it in the bulleted list. If I paid different prices for any of them, I’ll show the prices in the table instead.
- “Card reader used” indicates the card reader that was used for doing performance testing. In some cases, I’ve moved the card over to another card reader afterwards.
- I’m not done testing everything! I’ll update this page as I get more results.
ADATA Premier 32GB
- Obtained from: AliExpress
- Price paid: $2.99
- Advertised capacity: 32GB
- Size of protected area: 83,886,080 bytes
- Speed class markings: Class 10, U1, V10, A2
- CID data:
- Manufacturer ID:
0x1d
* - OEM ID:
0x4144
(ASCII:AD
)*
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to be associated with ADATA.
Discussion
ADATA is a brand that I’ve come across a few times now, during both my Amazon and AliExpress searches. They appear to be a fabless manufacturer based out of Taiwan. Seeing as how they’re a member of the SD Card Association, I’ll lump them in with the “name-brand” cards.
There appear to be (at least) two versions of this card floating around out there, possibly from two different manufacturers. One appears to be a little bit older (from early 2021), while the newer version is more recent (early 2023). Both versions performed about the same on sequential read tests; however, the older version scored slightly worse on sequential write tests, slightly better on random write tests, and significantly better on random read tests. On the downside, it was skimpier than the newer version.
Performance results for these cards were kinda all over the place. For example, as I mentioned above, sample #1 got a random read speed that was almost three times higher than the other two. Sample #2 also got pretty horrible read speeds on its first attempt, but were more in line with the scores from sample #3 on the second attempt.* Some samples got scores that were above average, while some got scores that were below average.
With the exception of sample #1’s random read scores, all scores came within one standard deviation of average. More specifically: sequential read speeds were above average, while all other scores (again, with the exception of sample #1) were below average. Sample #1 had a random read score that was more than one standard deviation above average; its sequential write score was below average, while its random write score was just average.
Endurance tests for all three cards are still ongoing:
- Sample #1 has not yet reached the 2,000 read/write cycle mark. It is currently expected to get there sometime in September 2024.
- Sample #2’s first error was a series of bit flips, affecting two sectors, during round 1,559. It has survived 1,657 read/write cycles in total so far.
- Sample #3’s first error was a 42,624-sector wide address decoding error during round 1. It continued to experience sector degradation over the following rounds, until it got to the point — during round 1,603 — where it stopped responding to commands.
* I don’t normally re-run performance tests — because performance can go down the longer a card has been in use — however, this card is being tested on my son’s server, on which he had some other workloads going that might have affected the outcome, and he needed to reboot the machine shortly after the endurance test started. This meant that I had to start my program over from scratch, because my program will refuse to resume from a save state if the endurance test hasn’t completed at least the first round of testing. The results of the second performance test came out much better, so I decided to go with the results of the second performance test.
August 29, 2024 (current number of read/write cycles is updated automatically every hour)
Amazon Basics 64GB
- Obtained from: Amazon
- Price paid: $9.41*
- Advertised size: 64GB
- Logical capacity: 63,281,561,600 bytes
- Physical capacity: 63,281,561,600 bytes
- Fake/skimpy flash: Skimpy (1.12% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 0.91%
- Speed class markings: Class 10, U3, V30, A2
- CID data:
- Manufacturer ID:
0xad
- OEM ID:
0x4c53
(ASCII:LS
) - Product name:
0x5553443030
(ASCII:USD00
) - Product revision:
0x10
- Manufacturer ID:
* These cards were sold as a two-pack; the price shown represents half the price of the two-pack.
Discussion
Amazon has been slapping their brand name on just about everything with their Amazon Basics brand — and microSD cards have been no exception. I don’t think I’ve ever bought any electronics in the Amazon Basics brand — so this will be a first for me.
Amazon obviously doesn’t have their own silicon foundries (or do they?), so there’s a question to be asked: who made this card? The sources that I normally go to don’t have anything on manufacturer ID 0xad
. I’ve seen this manufacturer ID (and OEM ID 0x4c53
) a few times now: with the Chuxia 32GB, the OV 32GB, and — most importantly — the Lexar Blue 633x 32GB. The Lexar brand was purchased by Longsys in 2017, so I think I’m just going to call it: I think manufacturer ID 0xad
belongs to Longsys. All of their cards that I’ve seen so far have OEM ID 0x4c53
— which, when translated into ASCII, becomes LS
— which I believe to be an abbreviation for Longsys. So yeah — I think these cards were manufactured for Amazon by Longsys.
Performance on these cards was decent. All scores were above average, with two of the three samples getting random write speeds that were more than one standard deviation above average. The lowest score was the sequential read speed on sample #3; at 89.65MB/sec, it came in at the 62nd percentile.
Endurance tests for all four cards are still ongoing:
- Sample #1 has survived 3,616 read/write cycles so far and has not yet experienced any errors.
- Sample #2’s first error was a four-sector wide address decoding error during round 956. It has survived 1,930 read/write cycles in total so far.
- Sample #3’s first error was a four-sector wide address decoding error during round 1,815. It has survived 1,945 read/write cycles in total so far.
- Sample #4 has not yet reached the 2,000 read/write cycle mark. It is estimated to reach this point sometime in November 2024.
October 1, 2024 (current number of read/write cycles is updated automatically every hour)
Amzwn 32GB
- Obtained from: AliExpress
- Price paid: $4.92
- Advertised capacity: 32GB
- Logical capacity: 31,954,305,024 bytes
- Physical capacity: 31,954,305,024 bytes
- Fake/skimpy flash: Skimpy (0.14% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: -0.12%
- Speed class markings: Class 10, U3, A2
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x3030303030
(ASCII:00000
) - Product revision:
0x00
- Manufacturer ID:
Discussion
Amzwn is a brand that appeared pretty frequently while I was browsing AliExpress — both when searching for microSD cards, and as recommendations on other products. They appear to come in various sizes, ranging from 32GB to 256GB. At least one version of their card (not this one) is labeled as “Amzwn basics”, with an arrow similar to the “A to Z” arrow used in Amazon’s logo appearing underneath the name. Combined with the similarity to Amazon’s name, this strongly suggests that they are hoping buyers will confuse them with Amazon.
Overall, I wasn’t terribly impressed with these cards. Read/write speeds were well below average — its best single score put it in the 25th percentile. No scores were high enough to warrant any of the speed class marks that it bears, with the exception of the Class 10 mark.
On the endurance front:
- Sample #1’s first error was a data verification failure affecting two sectors during round 1,536. It has survived 2,916 read/write cycles in total so far.
Sample #2 almost made it to the 2,000 read/write cycle mark without errors — but then it started failing, and hard. Its first error was a series of bit flip errors during round 1,988; by the end of round 1,989, those errors had affected over 1% of the total sectors on the device, and by the end of round 1,990, it had affected every sector. Here’s what the progression looked like:
Sample #3 experienced its first error early on, but that error was pretty minor — only affecting four sectors. It continued to experience sporadic errors over the next several hundred rounds, but again, those errors were relatively small — only affecting 56 sectors total over 1,720 read/write cycles. During round 1,721, however, it started experiencing a large number of bit flip errors. During round 1,722, those errors must have begun to affect the storage area that the card uses for the CSD data — because it suddenly began reporting itself as being 2TB in size. At that point I decided to declare the card dead. Here’s what this card’s progression looked like:
Overall, these cards were poor performers. On the bright side, they’re not fake flash; and while they were skimpy, they were definitely not the worst offenders. But would I buy them? Nah — there are WAY better options out there.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Auotkn Extreme 8GB
- Obtained from: AliExpress
- Price paid: $2.58
- Advertised capacity: 8GB
- Logical capacity: 8,053,063,680 bytes
- Physical capacity: 8,053,063,680 bytes
- Fake/skimpy flash: No
- Speed class markings: U1, V10
Discussion
Auotkn is another brand that came up frequently while browsing AliExpress. The visual design is almost identical to that used by SanDisk’s Extreme cards — to the point where a casual observer from 10 feet away likely wouldn’t notice the difference.
I initially found it curious that the first two cards displayed such wildly different results on the performance test. It wasn’t until I compared the CID data between the two — which, admittedly, I didn’t do until I was writing this up — that I noticed that they are completely different. Initially I thought that maybe I got the CID data mixed up with one of my other cards — after all, card #1 shared the same manufacturer ID, OEM ID, product name, and product revision as the one QEEDNS card I’ve tested, and sample #2 shared the same values as the Cloudisk and Bekit cards — but after rechecking the data, it appears that I recorded it correctly the first time. This points to the conclusion that Auotkn may be in the middle of switching manufacturers. Or that they source their cards from multiple manufacturers. Or that they’re reselling used cards. On second thought, maybe this doesn’t point to any conclusion in particular.
Regardless, the cards have performed well on their endurance tests. All three managed to endure well over 2,000 read/write cycles without any errors, making it only one of two models I’ve tested so far to do so. As of this writing:
Sample #1’s first true* error was a two-sector wide corrupted data error during round 3,013. It survived 4,772 read/write cycles; during round 4,773, the number of failed sectors exceeded the 50% threshold. Here’s a graph of what this sample’s progression looked like:
Sample #2's first error was a 1,668-sector wide corrupted data error during round 5,450. It survived 26,041 read/write cycles; during round 26,042, the number of failed sectors exceeded the 50% threshold. Here's a graph of what this sample's progression looked like:
Sample #3's first error was an eight-sector wide address decoding error during round 11,822. It was the third card in my collection to survive 10,000 read/write cycles (after sample #1 of the Hiksemi NEO 8GB and sample #3 of the Bekit 8GB). Like the other two, the number of failed sectors only increased as time went on; it finally reached the 50% failure threshold during round 20,961. Here's the graph for this sample:
Overall, while these cards have done well on endurance tests, the tradeoff is speed -- they performed terribly on all of their performance metrics. My advice is: don't buy them. There are better cards out there.
* Sample #1 experienced a failure during round 2,854, but this was due to problems with my code that handles disconnects/reconnects.
August 19, 2024
Auotkn Extreme 512GB
- Advertised capacity: 512GB
- Speed class markings: U1, V10
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $14.26 | $13.46 | $14.44 | $14.05 |
Manufacturer ID | 0x00 | Unknown | 0x56 | N/A |
OEM ID | 0x0000 | Unknown | 0x5344 (ASCII: SD ) | N/A |
Product name | 0x4150505344 (ASCII: APPSD ) | Unknown | 0x4150505344 (ASCII: APPSD ) | N/A |
Product revision | 0x00 | Unknown | 0x00 | N/A |
Serial number | 0x12800003 | Unknown | 0x0000018a | N/A |
Manufacture date | Mar 2023 | Unknown | Nov 2013 | N/A |
Logical capacity | Unknown | 536,871,960,576 bytes | 536,871,960,576 bytes | 536,871,960,576 bytes |
Physical capacity | Unknown | 31,596,637,696 bytes | 31,248,782,336 bytes | 31,422,710,016 bytes |
Fake/skimpy flash | Unknown | Fake flash | Fake flash | N/A |
Sequential read speed (MB/sec) | Unknown | 16.64 | 54.63 | 35.64 |
Sequential write speed (MB/sec) | Unknown | 12.54 | 15.05 | 13.80 |
Random read speed (IOPS/sec) | Unknown | 1,057.40 | 547.75 | 802.58 |
Random write speed (IOPS/sec) | Unknown | 0.46 | Unknown | 0.46 |
Read/write cycles to first error | 0 | 6 | 0 | 2 |
Read/write cycles to complete failure | 0 | 164 | 0 | 55 |
Total days to complete failure | 0 | 17 | 0 | 6 |
Card reader used | N/A | Prograde Digital Dual-Slot Mobile Reader | JJC CR-UTC4AC | N/A |
Package front | N/A | |||
Package back | N/A | |||
Card front | N/A | |||
Card back | N/A |
Discussion
After deciding to test the Auotkn Extreme 8GB, I purchased a single 512GB card, as I was curious to see if I would find the same manufacturer selling genuine flash and fake flash.
At first, I thought sample #1 was dead on arrival. The card was completely unresponsive whenever I plugged it in. I wasn’t sure if these cards were defective by design or if I had simply received a bad card, but I decided to give it the benefit of the doubt and ordered another one — from a different seller.
Initially, sample #2 was also unresponsive. I was about ready to call it dead on arrival as well, but then I decided to try it with the Prograde reader — and it worked. Unfortunately, I couldn’t use the Prograde reader to read the registers from the card — I’m only able to do that with the Realtek reader — so I wasn’t able to read the CID data from this card.
As I started working on my FPGA design, however, I decided to try out card #1 to see what it would do when the FPGA tried to initialize it. At first, the FPGA complained that the card sent back a response with a bad CRC. I had my logic analyzer hooked up to it, so I decided to do a capture and look at the communications going between my card and the FPGA. This is the command and response where my FPGA was telling me the response had a bad CRC:
Next, I hooked up one of my working cards and captured the same transaction with that one as well:
If you don’t know what you’re looking at: the top row (the blue signal) is the clock signal that my FPGA is sending to the card. The bottom row (the green signal) is the “CMD” line — it’s a bidirectional line that the host uses to send commands to the card, and that the card uses to respond to those commands. Coding is NRZL (basically — a high level represents a 1, a low level represents a 0). In the screenshots, the command and response start at the green dot and end at the red dot.
So as I stared at these captures, I was confused: they looked identical to me. Was the Auotkn sending back voltage levels that were enough for my logic analyzer to detect, but not enough for my FPGA to detect? Was there something wrong with the way I was calculating CRCs? Did a random wire get disconnected from my breadboard?
Eventually I decided to enable the signal tap logic analyzer, which lets you essentially see the signals that the FPGA is seeing — it’s kind of a debugger for the FPGA. I set it to trigger at the point where my card starts to listen for the response from the card, and here’s what I got:
What you’re seeing in the screenshot above is the FPGA’s view of the signals going back and forth over the card’s CMD line. The “0” represents the point where it started listening for the reply.
And seeing this, I suddenly realized what the issue was. When the card sends a reply back to the host, it’s supposed to start it with 00
(the first bit is a “start” bit, and the other bit indicates the direction — 0
for card to host, and 1
for host to card). However, my FPGA took a few clock cycles to switch from “sending mode” to “receiving mode”, and it didn’t have a chance to switch over to “receiving mode” until after the card sent the first bit of its reply back. The card was simply replying back too quickly! I adjusted my design to let the FPGA start listening for the reply sooner — and whaddya know, it was able to communicate with the card successfully, and I was able to query it for its CID! The CID data I have shown above is what I obtained from this process. I haven’t gotten my FPGA design to the point where it can do performance tests, however…so that will have to wait for another day.
This discovery led me to wonder — did my other card readers have this same deficiency in their design? Were they simply not starting to listen for the card’s reply soon enough? As far as I can tell, the SD card specification doesn’t say how many clock cycles the card is supposed to wait before replying back to the host, so I imagine the engineers that designed these card reader ICs never had to specifically think about this issue. I imagine I’ll probably never know for sure.
As I haven’t been able to do performance testing with sample #1, I only have results from sample #2 — and I have to say, they were pretty unimpressive. Unsurprisingly, this card’s physical capacity was not 512GB; its actual capacity was closer to 32GB. The sequential read/write speeds were barely enough to qualify for the U1 and V10 markings that it carries. Additionally, this card only lasted a few read/write cycles before it began showing data mismatch errors; and when it started failing, it failed quickly. By the time the card reached 164 read/write cycles, over half of the sectors on the card had been flagged as bad due to data mismatches.
I do find it interesting to look at exactly what symptoms a card shows when it starts to fail. In this case, some sectors showed a number of bit flips; others simply read back as all ff
‘s.
Here’s what the track record for this sample looks like:
As you can see, this sample’s endurance test went as follows:
- A few rounds of nothing (or practically nothing);
- A sudden jump to “halfway to the 50% failure threshold”;
- A slow rise in the number of bad sectors for about the next 150 read/write cycles;
- A sudden jump to “almost 50% of the sectors have failed”;
- And finally, the card becomes unresponsive.
I had to search around a bit for sample #3 — the original seller that I purchased the first two from no longer seemed to carry this card, and many of the other options I saw would have put me over my $15 budget. However, I eventually found one. When I started putting it through testing, however, it decided to self-destruct during performance testing — which is why I don’t have a random write score for this card.
My conclusion: don’t buy these cards. They’re absolute horse shit. They’re fake, and I haven’t had a single one of these that didn’t have issues right out of the package. Go spend your money on something like the Samsung PRO Endurance 32GB instead — you’ll pay about half as much for a much more reliable card.
June 1, 2024
Bekit 8GB
- Obtained from: AliExpress
- Price paid: $3.46
- Advertised capacity: 8GB
- Logical capacity: 8,032,092,160 bytes
- Physical capacity: 8,032,092,160 bytes
- Fake/skimpy flash: No
- Protected area: 50,331,648 bytes (inaccessible)
- Speed class markings: Class 6, U1
- CID data:
- Manufacturer ID:
0xfe
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344313647
(ASCII:SD16G
) - Product revision:
0x20
- Manufacture date: Nov 2022
- Manufacturer ID:
* I think. Earlier on in this project, I didn’t specifically write down which card reader I used on any given card, so some of this was going off of memory, and some of it was going off of what the card was plugged into when I wrote this.
Discussion
This brand took a little bit more digging to find, but once it came up, the colorful design caught my attention. What can I say. (Squirrel!)
Performance was good enough to merit the speed class marks it bore, and it approached the maximum practical sequential read speed for a UHS-I-compatible card, but sequential write speeds and random I/O speeds were disappointing. Sequential read speeds were above average, but all other performance metrics were below average — with sample #3 getting a random read speed that was more than one standard deviation below average.
Sample #1 lasted just shy of 1,600 read/write cycles before it failed. Just before failure (starting with round 1,573), it experienced a few rounds where a handful of sectors had data mismatch errors. However, during round 1,583, the device spontaneously changed capacity to 127MB (specifically, to 127,139,840 bytes). At that point, I decided to consider it “dead”. I’ll note that in versions 2 and 3 of the CSD register specification, the size of the card is indicated by adding 1 to the value of the C_SIZE
field, then multiplying it by 524,288. Since 127,139,840 is not a multiple of 524,288, it suggests that (at least) the portion of the card controller’s code responsible for populating the CSD register was corrupted, possibly causing it to report that it was using version 1 of the CSD register specification instead.
Here’s what the track record for the endurance tests for sample #1 looked like:
Interestingly, sample #2 also reported its capacity as 127MB right out of the package. Given that the other two cards initially reported their capacities correctly — and the fact that it would not respond to commands when plugged into my Realtek reader — I decided to declare this card “dead on arrival”.
Sample #3, on the other hand, did quite well: its first error was a corrupted data error during round 13,759. It survived 18,913 read/write before it got to the point where it would throw an error on every write attempt. It was the second card in my collection to hit 10,000 read/write cycles completed without errors (after sample #1 of the Hiksemi NEO 8GB). So I guess 1 out of 3 is…better than nothing?
Overall, I was impressed by the fact that the card did well on sequential read speeds, but this appears to be where its advantages end. The sequential write speeds and random I/O speeds were all below average, and endurance for 2 out of the 3 cards was below expectations.
My recommendation? Don’t buy these. There are better options out there.
September 2, 2024
Chuxia 32GB
- Obtained from: AliExpress
- Price paid: $5.78
- Advertised capacity: 32GB
- Logical capacity: 31,719,424,000 bytes
- Physical capacity: 31,719,424,000 bytes
- Fake/skimpy flash: Skimpy (0.88% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.61%
- Speed class markings: Class 10, U1, V10, A1
- CID data:
- Manufacturer ID:
0xad
- OEM ID:
0x4c53
(ASCII:LS
) - Product name:
0x5553443030
(ASCII:USD00
) - Product revision:
0x10
- Manufacture date: Apr 2023
- Manufacturer ID:
Discussion
Chuxia is another brand that took a little bit more digging to find, but caught my attention because of its original design.
I’m honestly not sure why I got such wildly different results between the different samples, especially on the random read test. If the random read speed for sample #2 is accurate, it would be the highest random read speed of any card I’ve tested so far. However, the fact that the other two performed so terribly in comparison makes me think that this was a fluke. The CID registers on all three samples were identical (except for the serial number), so I don’t think sample #2’s results could easily be attributed to a different model or different manufacturer. If you include Sample #2’s figures, this card performed average in random read speeds. If you exclude them, this card performed well below average (by more than one standard deviation). Either way you look at it, the card performed below average on sequential read and sequential write speeds, and well above average (more than one standard deviation) on random write speeds. All three performed well enough to qualify for the Class 10, U1, and V10 markings; however, only sample #2 performed well enough for the A1 marking.
All three samples are still undergoing endurance testing; however, the results so far were not too great, with two of the three experiencing errors before hitting the 2,000 read/write cycle mark:
- Sample #1’s first error was four-sector wide corrupted data error during round 1,384. It has survived 8,836 read/write cycles in total so far.
- Sample #2 is the only one that made it past the 2,000 read/write cycle mark without errors. It had its first error — which was a series discontiguous corrupted data errors — during round 4,339. It has survived 11,110 read/write cycles in total so far.
- Sample #3’s first error was a six-sector wide address decoding error during round 114. It was doing quite well until round 4,437, when it decided to return repeating sequences of
00 00 06 00
in every sector. (Funnily enough, this pattern repeated throughout each sector, except for the last 16 bytes of each sector — which were all00
‘s).
My conclusion: eh. These cards aren’t the greatest performers. They’re not the worst performers by far — but there are better options out there for the money.
August 5, 2024 (current number of read/write cycles is updated automatically every hour)
Cloudisk 32GB
- Obtained from: AliExpress
- Price paid: $3.52
- Advertised capacity: 32GB
- Logical capacity: 31,457,280,000 bytes
- Physical capacity: 31,457,280,000 bytes
- Fake/skimpy flash: Skimpy (1.70% skimp)
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10, U1, A1
- CID data:
- Manufacturer ID:
0xfe
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344313647
(ASCII:SD16G
) - Product revision:
0x20
- Manufacture date: Jul 2023
- Manufacturer ID:
Discussion
This card was unusual in the fact that it did not come in a retail package — instead, it came in a simple plastic case.
All three samples performed well enough on the performance tests to qualify for the Class 10 and U1 markings; however, none of them performed well enough to qualify for the A1 marking. As we’ve established previously, my tests don’t conform to the tests described in the SD Physical Layer Specification — so maybe these cards would have performed better under the right conditions…but somehow I doubt it (especially seeing as how I have other cards that did perform well enough to qualify for the A1 marking).
On the endurance front:
Sample #1 did make it past the 2,000 read/write cycle mark without encountering any errors — but just barely. Its track record was pretty boring — but here it is:
Like I said, it’s pretty boring: nothing happens until round 2,077 — where barely anything happens — and then nothing happens for another 100 rounds or so before the card becomes unresponsive.
Sample #2 encountered its first error after 1,516 read/write cycles. I finally declared it dead at the end of round 2,279, when the number of bad sectors reached the 50% threshold. Here’s what its progress graph looked like:
Sample #3 experienced its first error during round 876. I don’t know the nature of the error, but it affected over 5% of the sectors on the device in one round — but by the next round, those same sectors did not experience any errors. It continued to experience data verification failures over the next 2,700 or so read/write cycles; it was finally declared “dead” once 50% of the sectors on the card had experience data verification failures. Here’s what the graph of this sample’s progression looked like:
My conclusion: eh. These weren’t the worst performers in my collection, but it sure seemed like they were for a while. There are better options out there for the money.
July 5, 2024
Delkin Devices HYPERSPEED 128GB
- Obtained from: Amazon
- Price paid: $12.99
- Advertised capacity: 128GB
- Logical capacity: 124,688,269,312 bytes
- Physical capacity: 124,688,269,312 bytes
- Fake/skimpy flash: Skimpy (2.59% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 2.48%
- Speed class markings: U3*, V30
- CID data:
- Manufacturer ID:
0x27
** - OEM ID:
0x5048
(ASCII:PH
)** - Product name:
0x5344313238
(ASCII:SD128
) - Product revision:
0x60
- Manufacturer ID:
Discussion
These cards have the same manufacturer ID, the same OEM ID, the same product name, and the same product revision as the PNY Premier-X 128GB. So they should perform exactly the same, right?
As it turns out, no — at least, not based on this one sample. Well…almost.
Sequential write, random read, and random write speeds were pretty in line with the PNY Premier-X 128GB, but sequential read speeds were considerably worse. And it’s not like the card did well initially and then worse as it went on — I watched it, and it did about 50MB/sec pretty consistently across the entire test. It’ll be interesting to see what the other two samples do.
Endurance tests for sample #1 are still ongoing. It has not yet reached the 2,000 read/write cycle mark; it is currently expected to get there sometime in December 2024.
Samples #2 and #3 are still in the package waiting to be tested.
September 7, 2024
Gigastone Full HD Video 32GB
- Obtained from: Amazon
- Advertised capacity: 32GB
- Logical capacity: 31,164,727,296 bytes
- Physical capacity: 31,164,727,296 bytes
- Fake/skimpy flash: Skimpy (2.61% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 2.35%
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x3030303030
(ASCII:00000
) - Product revision:
0x00
- Manufacturer ID:
Discussion
I had tried to start this project a couple years back, and sample #1 was one that I purchased as part of that effort. I lost track of some of the SD cards I purchased for the project, however; and instead of simply buying new ones, I was determined to figure out what happened to them — and lost interest in the project after I failed. Back then, my goals and methods were not as well defined, and thus I don’t have as much data on sample #1 as I do on many of the other cards in my collection.
For sample #1:
- Capacity was determined using f3probe. I don’t recall what the card’s physical capacity was, only that it matched the card’s logical capacity. The logs from stressdisk would suggest that the card’s capacity was somewhere between 29.2GB and 30.6GB. (This was based off of the “bytes written” statistic that stressdisk periodically writes to the logs. It’s measured in “Mbytes”, and I don’t know if they used 1,000,000 or 1,048,576 bytes per megabyte). If this is correct, then on the low end, this card would have a skimp factor approaching 5%, and on the high end, would be closer to 9%. Remember that according to my criteria that I laid out earlier, anything with a skimp factor over 5%
- Endurance testing was performed using stressdisk. While my other test rigs are laptops using Intel Core i7 processors, this card was tested on a Rock64 single-board computer, so it’s possible that CPU speeds could have been a bottleneck on performance. And, while I didn’t run proper speed tests, stressdisk did periodically log the average read/write speeds that it had been seeing — and the last numbers it recorded before the card failed were a read speed of 80.66MB/sec and a write speed of 23.74MB/sec. If this had represented a proper sequential I/O test, it would put it slightly above average for read speeds and slightly below average for write speeds, but good enough to qualify for the Class 10 and U1 markings that it bore.
The notable disadvantage to using stressdisk is that it operates at the filesystem level — it writes files of a predetermined size to the filesystem, then reads them back in a random order. This means that it’s not able to evenly test the entire user area of the flash, as space for things directory structures, file allocation tables, boot sectors, etc., would get written to at a different frequency than the test files. It’s possible that this card would have behaved slightly differently — perhaps it would have failed sooner or later than it did — had the entire user area of the card been tested evenly instead. Stressdisk also deleted any partial files that it wrote (e.g., due to running out of space on the card) without verifying them — so any data integrity errors in the portion of the card occupied by that space would have gone undetected. This is not to say that there is not value in testing a card using a tool like stressdisk — it could be argued that the type of test run by stressdisk better simulates how something like a digital camera or digital video camera would use a card. However, for my purposes, I want to make sure the entire user area of the card is tested. That said, however, this card was able only able to endure 1,785 read/write cycles before it failed. Once it failed, it became completely unresponsive to commands from the reader.
I eventually decided that it would be good to get some more samples of this card and run them through the same suite of tests as my other cards. Fortunately, they are still in plentiful supply on Amazon.
Upon examining the CID data for sample #2, I was honestly surprised to see the manufacturer ID zeroed out. All of the other cards I’ve tested that have the manufacturer ID zeroed out like this have been fake flash or low-quality flash, and the manufacturer likely zeroed it out because they don’t want it to be traced back to them. This is not a particularly good sign, especially for a card that has made an appearance in at least one major retailer in the US market.
If I were to go down the rabbit hole of “who made this”, there’s a couple other clues I could go off of:
- Of the other cards in my collection, OEM ID
0x3432
has only appeared with cards that have their manufacturer ID set to0x00
and0xfe
. This would put it into the same category as Cloudisk, Bekit, Auotkn, Reletech, SomnAmbulist, and — notably — the 128GB version of the HP microSDXC mx330. - Of the other cards in my collection, product name
00000
has only appeared with cards that have their manufacturer ID set to0x9f
. This would put it into a slightly more reputable category — which includes the Amzwn 32GB, Kodak Ultra Performance 32GB, the Kingston Industrial 8GB, and SP Elite 32GB. However, the upper four bytes of the serial number is zeroed out as well — and with the exception of the Amzwn 32GB, the other cards didn’t do this — so this might indicate that whoever manufacturer ID0x9f
belongs to, they weren’t involved in the production of this card. - Another thing we could look at is the laser etching on the back of the card — the font used, the orientation, the numbering scheme, the way in which “Made in Taiwan” is capitalized, etc. I wasn’t able to find any exact matches here, but there are several that come close: the Amzwn 32GB, the Auotkn Extreme cards, the Microdrive “Bart Simpson” 16GB, the PNY cards, the QEEDNS cards, the SanDian cards, many of the SanDisk cards, the “Sansumg” Pro Plus 2TB, the “Sony” 1024GB, and the “Xiaomi” 16GB all appear to use a similar font. Coincidentally, almost all of these (with the exception of the “Sansumg” Pro Plus 2TB) also bear some sort of “Made in Taiwan” mark — the others were manufactured elsewhere. The closest match, however, appears to be the “Xiaomi” 16GB.
I think the most interesting possibility here is the PNY cards — particularly the “Made in Taiwan” etching, which appears to have been added separately from the other etchings on the card. The font seems to be a dead-on match, the capitalization is the same, and — most notably — PNY is a brand name. They know who manufactured their cards; I’m willing to bet that whoever manufactured their cards manufactured these cards as well.
Performance scores so far have been disappointing. Sequential read scores were a little bit above average, but all other scores were slightly below average.
Sample #2-#4 are currently going through endurance testing:
- Sample #2’s first error was a four-sector wide address decoding error during round 382. It has survived 2,139 read/write cycles in total so far.
- Sample #3 has not yet reached the 2,000 read/write cycle mark. It is expected to get there sometime in October 2024.
- Sample #4’s first error was a series of bit flips, affecting 10 sectors, during round 2,096. It has survived 3,252 read/write cycles in total so far.
Samples #5 and #6 are currently in the package waiting to be tested.
September 15, 2024 (current number of read/write cycles is updated automatically every hour)
Hiksemi NEO 8GB
- Obtained from: AliExpress
- Price paid: $1.03
- Advertised capacity: 8GB
- Logical capacity: 7,989,624,832 bytes
- Physical capacity: 7,989,624,832 bytes
- Fake/skimpy flash: Skimpy (0.13% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: -1.55%
- Speed class markings: Class 10
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0303
- Product name:
0x4342414453
(ASCII:CBADS
*) - Product revision:
0x10
- Manufacturer ID:
* Keen-eyed observers might note that other cards in my survey have a product name of SDABC
, and that this is simply that, but backwards. I wonder if there’s an inside joke here?
** I think
Discussion
When I first started searching for SD cards on AliExpress, I decided to sort by price from lowest to highest — and Hiksemi was a result that came up near the top of the list. At the time, they were selling the 8GB card for just $0.01 — but that was before shipping. Still, I have to say that it’s a pretty effective strategy for getting people’s attention, and the card is still an excellent value even when factoring in shipping costs.
Honestly, though, I have to say that I was pleasantly surprised by Hiksemi’s cards as a whole. This card’s only speed class marking is a Class 10 mark, which it easily qualified for. Sequential read and write speeds were well above average (with sequential read speeds being towards the high end of the spectrum). Random read speeds were average (with sample #1 being above average, and samples #2 and #3 being slightly below average), and random write speeds were all above average.
Endurance is where these cards have really shined. As of the time of this writing:
- Sample #1 has survived 70,171 read/write cycles so far and has not yet experienced any errors — far more than any other card in my collection thus far. It has also gone the longest without errors out of any of the cards in my collection, having gone nearly-continuously for 302 days without experiencing any errors. And, it’s also endured the most bytes written out of any of the cards I’ve tested so far, at 400.91TiB.
Sample #2’s first error was a 32-sector wide corrupted data error during round 3. However, it did not experience any further errors until round 5,918, when it began to experience a large number of missing data errors. It reached the 50% failure threshold during this round, and the test was considered complete at that point. Below is a graph showing this sample’s progression:
- Sample #3’s first error was a two-sector wide data verification error that occurred during round 15,935. It has survived 19,885 read/write cycles in total so far.
Overall, would I buy this cards again? Yes! It was a complete surprise to me, but this card scored above average in every category. The only downside is that it seems that they’re no longer available at the price point I bought them at — there are other sellers on AliExpress that are selling (what appears to be) the same card, but by the time you add in shipping, the price ends up being between 3-6x what I paid.
July 5, 2024 (current number of read/write cycles is updated automatically every hour)
Hiksemi NEO 32GB
- Obtained from: AliExpress
- Logical capacity: 31,271,157,760 bytes
- Physical capacity: 31,271,157,760 bytes
- Fake/skimpy flash: Skimpy (2.28% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 1.86%
- Speed class markings: V10
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0305
- Product name:
0x455a534431
(ASCII:EZSD1
) - Product revision:
0x10
- Manufacturer ID:
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $1.93 | $1.93 | $6.61 | $3.49 |
Manufacture date | Apr 2023 | Apr 2023 | Mar 2023 | N/A |
Serial number | 0xaa03c26c | 0xaa020f88 | 0xaa021111 | N/A |
Sequential read speed (MB/sec) | 89.20 | 90.85 | 90.28 | 90.11 |
Sequential write speed (MB/sec) | 27.10 | 38.61 | 22.55 | 29.42 |
Random read speed (IOPS/sec) | 2,001.52 | 1,790.34 | 1,878.15 | 1,890.00 |
Random write speed (IOPS/sec) | 402.03 | 360.17 | 374.97 | 379.06 |
Read/write cycles to first error | 7,940 | 1,939 | 1,392 | 4,230 |
Read/write cycles to complete failure | 10,893 | Not yet determined | Not yet determined | 10,893 |
Total days to complete failure | 408 | Not yet determined | Not yet determined | 408 |
Card reader used | SmartQ Single | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | N/A | |||
Package back | Not available | N/A | ||
Card front | N/A | |||
Card back | N/A |
Discussion
While not quite as impressive as their smaller siblings, these cards are still pretty impressive overall. Their main disadvantage is that they did markedly worse on sequential write speeds, coming out just “average” in this category. Initially, I only ordered two — for the simple reason that, at the time, AliExpress would only let me order two. I went back and ordered a third after I made the decision to try to test at least 3 samples of each model.
All three samples are currently undergoing endurance testing:
Sample #1 was initially plugged into a SmartQ Single reader. As I noted earlier, I’ve had problems with these readers randomly failing every few days — and this one was no exception — so I eventually moved it over to one of the JJC CR-UTC4AC’s. Its first legitimate* error was a four-sector wide address decoding error that occurred during round 7,941. It continued to chug along for another couple thousand rounds until round 9,450, when large swaths of sectors just started returning all
ff
‘s — and then going back to normal during the next round. This continued until round 10,894, when the problem had affected over 50% of the total sectors on the device — at which point the endurance test was considered “complete”. Here’s the graph of this card’s progression through the endurance test:- Sample #2 just barely missed the 2,000 read/write cycle mark — it experienced a 64-sector wide data verification error during round 1,940. It has endured 5,703 read/write cycles in total so far.
- Sample #3’s first error was a four-sector wide address decoding error during round 1,324. It has survived 5,023 read/write cycles so far.
Overall, would I buy these cards again? Maybe. They’re definitely not a bad card — they scored about on par with the SanDisk Ultra 32GB (except for random read speeds, where the SanDisk Ultra performed about twice as well), they endured better, and they’re priced about the same — so if you’re trying to choose between the two, I think it just depends on whether endurance or random read speeds are more important to you.
* This card did technically suffer some errors earlier in the test. However, I have code to handle device disconnects/reconnects — and it took me a while to get this code right, so I chalked up these errors to issues with my code.
October 1, 2024 (current number of read/write cycles is updated automatically every hour)
Hiksemi NEO 128GB
- Obtained from: AliExpress
- Advertised capacity: 128GB
- Logical capacity: 125,085,155,328 bytes
- Physical capacity: 125,085,155,328 bytes
- Fake/skimpy flash: Skimpy (2.28% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 2.17%
- Speed class markings: V30
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0305
- Product name:
0x455a534431
(ASCII:EZSD1
) - Product revision:
0x10
- Manufacturer ID:
Discussion
After being initially impressed by the Hiksemi NEO 8GB, I went back to see what other options Hiksemi had available. I must have caught the 128GB while it was on sale (or mispriced), because they were priced at only $1.74 before shipping. Even after shipping, these cards are still an excellent value, coming out to just over 3 cents per gigabyte. The only reason why sample #3 was more expensive is because I gave one to a friend, then went back and re-ordered a replacement; the price had gone up in the meantime.
On the performance front, this is another instance where it feels like Hiksemi undersold the performance of their cards; both samples I’ve tested so far easily surpassed the benchmark for the only performance mark that they bore, the V30 mark. Sequential write speeds on all three samples were more than one standard deviation above the average, putting them in the 85th percentile.
All three samples are still undergoing endurance testing. These cards will obviously take longer to complete their endurance test given their size relative to the others in the survey — they are averaging about 4-8 read/write cycles per day.
- Sample #1’s first error was a four-sector wide address decoding error during round 2,273; it has survived 3,057 read/write cycles in total so far.
- Sample #2 experienced a two-sector wide data verification error during round 110; it has survived 2,032 read/write cycles in total so far.
- Sample #3’s first error was an 8-sector wide data verification error during round 515. It has survived 1,324 read/write cycles in total so far.
I’m a little disappointed that these cards didn’t fare quite as well on endurance tests as their smaller siblings — it looks like, in these cards at least, endurance was more a factor of time rather than read/write cycles. But overall, I feel like Hiksemi has been an unexpected standout among the cards I’ve tested. They’re priced very competitively, and perform as well as — or even better than — many of their name-brand competitors.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
HP MicroSDXC mx330 64GB
- Obtained from: AliExpress
- Price paid: $2.59
- Advertised capacity: 64GB
- Logical capacity: 62,226,694,144 bytes
- Physical capacity: 62,226,694,144 bytes
- Fake/skimpy flash: Skimpy (2.77% skimp)
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0x27
* - OEM ID:
0x5048
(ASCII:PH
)* - Product name:
0x5344363447
(ASCII:SD64G
) - Product revision:
0x60
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to be associated with Phison.
Discussion
This is another card that came up as part of AliExpress’s “pick up to 10 items” sales. Looking at these cards, I’m not sure how they ended up in the Chinese market — there’s no Mandarin text on the package, and the languages that are on there (plus the presence of an EAN) tells me that these cards were likely intended for retail in Europe. But regardless, they made their way to China — or possibly never left China — so let’s take a closer look at them.
Even before opening the package, it’s pretty obvious that these cards were sourced from PNY. For starters, you can see PNY’s website in the authenticity seal on the front:
Second, there are support emails on the back that are at PNY.com:
And lastly, there are regulatory marks on the back that list PNY as the applicant:
So…these were made by (or sourced from*) PNY under license from HP.
But how well do they perform? Well…actually, pretty decent. All scores were above average, with two of the three cards getting random read scores that were more than one standard deviation above average, and all three cards getting random write scores that were more than two standard deviations above average. They scored in the 82nd percentile for random read speed, and in the 95th percentile for random write speeds. In fact, the lowest of all the performance measurements — which was the sequential write speed on sample #1 — put it in the 73rd percentile.
These cards carry the U3, V30, and A1 marks — and they performed well enough to qualify for all three of them. Not a bad deal for under $3.
Endurance tests for all three samples are still ongoing:
- Sample #1’s first error was a single bit flip error, in a single sector, during round 1,113. It has survived 1,785 read/write cycles in total so far.
- Sample #2’s first error was a single bit flip error, in a single sector, during round 640. It has survived 1,785 read/write cycles in total so far.
- Sample #3’s first error was a single bit flip error, in a single sector, during round 545. It has survived 1,832 read/write cycles in total so far.
* The manufacturer ID being used by these cards is assigned to Phison — so it would seem that PNY licensed the naming rights from HP, then had Phison manufacture the cards for them.
August 7, 2024 (current number of read/write cycles is updated automatically every hour)
HP MicroSDXC mx330 128GB
- Obtained from: AliExpress
- Price paid: $4.69
- Advertised capacity: 128GB
- Logical capacity: 125,069,950,976 bytes
- Physical capacity: 125,069,950,976 bytes
- Fake/skimpy flash: Skimpy (2.29% skimp)
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0xfe
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344000000
(ASCII:SD
) - Product revision:
0x20
- Manufacturer ID:
Discussion
After purchasing the 64GB version of this card, I saw the 128GB version pop up in AliExpress’s bundle sales and decided to snatch it up. At first glance, this would appear to be identical to the 64GB sibling, just in a higher capacity — the card artwork is the same, and the package is the same, except for the 128GB mark instead of the 64GB mark — however, on closer inspection, this isn’t the case. This is an interesting case study in how two different cards — that can appear to be the same model, just different capacities — can be completely different products.
Like I said, both cards are in almost identical packaging, including the allusions to PNY being the underlying vendor. The artwork on the front of the card also appears to be identical — although from the pictures, it looks like there’s a difference in the shade of purple that was used between the two. I didn’t look closely at this in person before starting the testing process, so it could simply be differences in lighting between the two sets of pictures. Looking at the back of the card, however, you can tell that the style of printing is completely different between the two.
And, plugging it in, we can see that the manufacturer IDs/OEM IDs are completely different — the 64GB version uses manufacturer ID 0x27
— which is pretty well known to belong to Phison — while this version uses manufacturer ID 0xfe
. I don’t know who this manufacturer ID belongs to exactly, but I’ve only ever seen it with off-brands before now — the Auotkn Extreme 8GB, Bekit, Cloudisk, and Reletech.
All of this points to the conclusion that PNY went with a cheaper manufacturer for the 128GB version — and it shows in the results. This card got sequential write scores that were more than one standard deviation above average — with the lowest of the three scores putting it into the 90th percentile — but it only goes downhill from there. Two of the three got sequential read scores that were only a little bit above average, but the third got a score that was pretty far below average. All three got random write scores that were below average, while two of the three got random read scores that were more than one standard deviation below average. (The third got a score that was just under one standard deviation below average.) This is a stark contrast to the 64GB version produced by Phison, where every sample got above average scores in every category.
The card bears the U3, V30, and A1 markings. While it performed well enough to qualify for the U3 and V30 markings, the abysmal random I/O performance put it far short of the level it needed to be at to qualify for the A1 marking. Perhaps these cards would have done better had then been tested under proper conditions…but somehow, I doubt it.
Endurance tests for all three cards are still ongoing.
- Sample #1’s first error was a single bit flip, in a single sector, during round 758. It has survived 1,172 read/write cycles in total so far.
- Sample #2 has not yet reached the 2,000 read/write cycle mark. It is currently expected to get there sometime in January 2025.
- Sample #3’s first error was a single bit flip, in a single sector, during round 680. It has survived 1,144 read/write cycles in total so far.
August 28, 2024 (current number of read/write cycles is updated automatically every hour)
Kingston Canvas Go! Plus 64GB
- Obtained from: AliExpress
- Price paid: $5.19
- Advertised capacity: 64GB
- Logical capacity: 62,226,694,144 bytes
- Physical capacity: 62,226,694,144 bytes
- Fake/skimpy flash: Skimpy (2.77% skimp)
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: Class 10*, U3, V30, A2
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x5344363447
(ASCII:SD64G
) - Product revision:
0x61
- Manufacturer ID:
* The Class 10 marking appears on the product packaging, but does not appear on the card itself.
Discussion
Holy hell. I’m…uh…I’m gonna need a minute to pick my jaw up off the floor.
This card is the second model of Kingston’s I purchased, but the third that I tested (because I purchased the Kingston Industrials and started testing them before starting testing on these cards). Like the Canvas Select Plus, they bear the color-shifting stripe on the edge of the card, presumably to reassure buyers that the card is genuine:
Ok, let’s get down to brass tacks: this card absolutely smoked the competition in terms of performance — even managing to outperform the Lexar Professional 1000x. All three cards had sequential read speeds, sequential write speeds, and random write speeds that were faster than anything else I’ve tested so far. Sequential read and sequential write speeds for all three samples were more than two standard deviations above average, and random write speeds were more than three standard deviations above average. In statistics terms, this means that this card performed better on sequential read and sequential write speeds than 95% of the cards out there, and better than 99.7% of the cards out there on random write speeds (assuming that the cards I’ve tested are representative of the general population of microSD cards on the market). Random read speeds were not the fastest, but were still respectable: two of the three scores were more than one standard deviation above average, while the third was just shy of one standard deviation above average.
This card bears the U3, V30, and A2 marks, while the package also bears the Class 10 mark. It easily surpassed the requirements for the Class 10, U3, and V30 marks. The A2 mark is a difficult one to meet — it requires a random read speed of at least 4,000 IOPS/sec and a random write speed of 2,000 IOPS/sec — and this one fell short of the mark. However, they performed well enough that I’ll say — and I mean it — that perhaps they would have hit these marks had they been tested under proper conditions.
Clearly, someone felt the need for speed when designing this card. If you need something to support high speed photograph/videography, I dare say — barring the results of the endurance test — that this is the card to go with.
Endurance tests for all three cards are still ongoing:
- Sample #1 has survived 2,654 read/write cycles so far and has not yet experienced any errors.
- Sample #2’s first error was a single bit flip, in a single sector, during round 1,746. It has survived 2,643 read/write cycles in total so far.
- Sample #3 has not yet reached the 2,000 read/write cycle mark. It is currently expected to get there sometime in November 2024.
September 10, 2024 (current number of read/write cycles is updated automatically every hour)
Kingston Canvas Select Plus 32GB
- Advertised capacity: 32GB
- Logical capacity: 30,945,574,912 bytes
- Physical capacity: 30,945,574,912 bytes
- Fake/skimpy flash: Skimpy (3.30% skimp)
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10*, U1, V10, A1
- CID data:
- Manufacturer ID:
0x27
** - OEM ID:
0x5048
(ASCII:PH
)** - Product name:
0x5344333247
(ASCII:SD32G
) - Product revision:
0x60
- Manufacturer ID:
Sample # | 1 | 2 | 3 | 4 | 5 | 6 | Average |
---|---|---|---|---|---|---|---|
Obtained from | Amazon | AliExpress | Amazon | AliExpress | Amazon | AliExpress | N/A |
Price paid | $8.30 | $4.48 | $8.30 | $4.48 | $8.30 | $4.48 | $6.39 |
Manufacture date | Feb 2023 | May 2023 | Feb 2023 | May 2023 | Feb 2023 | May 2023 | N/A |
Serial number | 0x6c5202a6 | 0x01af9781 | 0x6c5202f6 | 0x01aab823 | 0x6c51ea11 | 0x01af8750 | N/A |
Sequential read speed (MB/sec) | 91.36 | 90.92 | 91.23 | 86.30 | 90.83 | 91.48 | 90.35 |
Sequential write speed (MB/sec) | 38.28 | 42.58 | 36.42 | 40.62 | 36.95 | 40.62 | 39.25 |
Random read speed (IOPS/sec) | 2215.15 | 2390.59 | 2072.70 | 3729.20 | 2407.14 | 2334.70 | 2524.91 |
Random write speed (IOPS/sec) | 590.49 | 638.31 | 580.48 | 688.02 | 588.55 | 633.21 | 619.84 |
Read/write cycles to first error | 479 | 3,528 | Not yet determined | 2,729 | 126 | 5 | 1,373 |
Read/write cycles to complete failure | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
Total days to complete failure | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
Card reader used | Lexar LRWM05U-7000 | JJC CR-UTC4AC | JJC CR-UTC4AC | JJC CR-UTC4AC | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | N/A | ||||||
Package back | N/A | ||||||
Card front | N/A | ||||||
Card back | N/A |
* The Class 10 mark appears on the product packaging, but does not appear on the card itself.
** This manufacturer ID/OEM ID is well known to be associated with Phison Electronics Corporation.
Discussion
I have something of a bias against Kingston cards. I have a number of single-board computers that use microSD cards as their boot device; and while I’ve typically used SanDisk cards for this, occasionally a Kingston card or two has found its way into the mix, and it seems like the Kingston cards have always failed long before any of the SanDisk cards have. However, these are just anecdotes — I don’t have any hard data to back up the idea that Kingston cards are less reliable than other brands. Because of this, I wanted to give them a fair chance to prove themselves — so I purchased three from Amazon and three from AliExpress.
The US and Chinese versions of the cards are — as far as I can tell — identical. The CID data (with the exception of the manufacture date and serial number) is identical between the two versions. They all performed pretty similarly in performance tests. The exterior also appears to be identical, including this interesting color-shifting stripe on the left edge:
I know that when Bunnie (of Bunnie Studios) went looking for various Kingston cards in the Chinese markets, he described at least one instance where he saw non-Kingston cards being put into Kingston retail packaging — so I suspect that Kingston did this as a way to assure buyers that these cards were authentic.
The primary difference between the US and Chinese versions seems to be the packaging. And curiously, there’s a notable difference here: the Chinese packaging is not tamper-evident. The card can be accessed by opening a simple flap on the front of the package; the card can be replaced, and the flap closed, without causing any damage to the packaging. If I were a retailer selling these in a physical storefront, I’d be forced to have them locked up in some fashion (security box, glass case, behind the counter, etc.) to make sure that unscrupulous customers couldn’t come into my store, steal the authentic Kingston cards, and replace them with cheap fakes.
Performance-wise, these cards actually did rather well. All cards scored above average in all performance metrics. Random write speeds for all cards being more than one standard deviation above average, with the lowest single score putting it in the 78th percentile. All cards easily met the thresholds for all of the performance marks that they bore (including the A1 mark — which most cards failed to meet).
These cards are later additions to my collection; as such, they are still undergoing endurance testing. As of this writing:
- Sample #1 experienced an address decoding error during round 480. It has survived 9,999 read/write cycles in total so far.
- Sample #2 experienced an eight-sector wide address decoding error during round 4,198; it has survived 6,300 read/write cycles in total so far.
- Sample #3 has survived 7,645 read/write cycles and has not yet experienced any errors.
- Sample #4 experienced a address decoding error during round 2,729. It has survived 12,120 read/write cycles in total so far.
- Sample #5 experienced an address decoding error during round 127, and experienced a few additional address decoding errors in later rounds, but has not experienced any further errors since round 1,941. It has survived 9,338 read/write cycles in total so far.
- Sample #6 experienced an address decoding error during round 6, and suffered occasional address decoding errors in later rounds. It has survived 7,596 read/write cycles in total so far.
So how well have these cards performed overall? Performance-wise, they’ve done great — they have some of the fastest random read and write speeds out of any of the cards I’ve tested. The tradeoff here seems to be endurance — half of these cards experienced their first error before hitting even the 500 read/write cycle mark. However, the incidence of errors has been pretty low so far — so if you need a card with decent performance for an application that can tolerate occasional failures, then this is a good option to go with.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Kingston Industrial 8GB
- Obtained from: Mouser Electronics
- Price paid: $13.93
- Advertised capacity: 8GB
- Logical capacity: 8,040,480,768 bytes
- Physical capacity: 8,040,480,768 bytes
- Fake/skimpy flash: No
- Size of protected area: 50,331,648 bytes (inaccessible)
- Speed class marks: Class 10*, U3, V30, A1
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x5344434954
(ASCII:SDCIT
) - Product revision:
0x61
- Manufacturer ID:
Discussion
Well, I seem to be on a quest to see not only which microSD card will endure the best, but also which industrial-grade microSD card will endure the best. I wasn’t able to find any on either Amazon or AliExpress — at least, none that were within my budget (although in hindsight, I realize that I may have not looked hard enough, because there absolutely were), so this card marks the first use of a supplier other than Amazon or AliExpress for this project.
Unlike the SanDisk Industrial 8GB, this card came in retail packaging. However, this card is missing the color-shifting stripe that the other Kingston cards have. If you look at the product pictures, it looks like the 8GB model is the only one that doesn’t have this stripe — the 16GB and larger versions all seem to have it.
So far, I’m actually liking this card. All performance metrics were above average, with write speeds (both sequential and random) being more than one standard deviation above average. The lowest single sequential write score puts it in the 81st percentile, while the lowest single random write score put it in the 88th percentile. This would actually make it faster than the SanDisk Industrial 8GB — and to boot, it’s not skimpy, whereas the SanDisk Industrial 8GB was.
All three samples are currently undergoing endurance testing.
- Sample #1’s first error was a two-sector wide address decoding error during round 8,801. It has survived 17,123 read/write cycles in total so far.
- Sample #2’s first error was a four sector wide address decoding error during round 6,368. It has survived 22,586 read/write cycles in total so far.
- Sample #3’s first error was a two-sector wide address decoding error during round 8,769. It has survived 22,611 read/write cycles in total so far.
August 5, 2024 (current number of read/write cycles is updated automatically every hour)
Kioxia Exceria 32GB
- Advertised capacity: 32GB
- Logical capacity: 31,243,370,496 bytes
- Physical capacity: 31,243,370,496 bytes
- Fake/skimpy flash: Skimpy (2.36% skimp)
- Size of protected area: 83,886,080 bytes (inaccessible)
- Speed class marks: C10*, U1
- CID data:
- Manufacturer ID:
0x02
** - OEM ID:
0x544d
(ASCII:TM
) - Product name:
0x5341333247
(ASCII:SA32G
) - Product revision:
0x71
- Manufacturer ID:
Sample # | 1 | 2 | 3 | 4 | Average |
---|---|---|---|---|---|
Obtained from | Amazon | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $11.49 | $6.15 | $6.15 | $6.15 | $7.49 |
Manufacture date | Unknown | Dec 2022 | Dec 2022 | Dec 2022 | N/A |
Serial number | Unknown | 0x498ff4cf | 0x498ff46a | 0x498ff471 | N/A |
Sequential read speed (MB/sec) | Unknown | 94.16 | 94.17 | 94.17 | 94.17 |
Sequential write speed (MB/sec) | Unknown | 18.08 | 17.74 | 17.91 | 17.91 |
Random read speed (IOPS/sec) | Unknown | 2,204.23 | 2,831.33 | 2,704.33 | 2,579.96 |
Random write speed (IOPS/sec) | Unknown | 865.49 | 878.90 | 867.76 | 870.71 |
Number of read/write cycles to first error | 2,568 | Not yet determined | Not yet determined | 923 | 1,746 |
Number of read/write cycles to complete failure | 2,568 | Not yet determined | Not yet determined | Not yet determined | 2,568 |
Total days to complete failure | 66 | Not yet determined | Not yet determined | Not yet determined | 66 |
Card reader used | SmartQ Single*** | JJC CR-UTC4AC | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | Not available | N/A | |||
Package back | Not available | N/A | |||
Card front | Not available | N/A | |||
Card back | Not available | N/A |
* The Class 10 marking appears on the product packaging, but does not appear on the card itself.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with Toshiba/Kioxia.
*** Probably
Discussion
This card is one that I first purchased in 2021, when I first tried to start this project. At that point in time, my project and its goals were not nearly as well defined, and as a result I don’t have as much data on that first card — so I wanted to get some fresh samples and put them through the same testing as all my other cards. Plus, I’ve reviewed two other models of Kioxia cards — why not review a third?
As with the Gigastone Full HD Video card earlier, I used a combination of f3probe and stressdisk to test the first sample. The logs from stressdisk indicate that the average read speed at the time of failure was 86.74MB/sec, while the average write speed was 18.38MB/sec. This was consistent with the scores I obtained on the later three samples.
These cards have decent sequential read, random read, and random write speeds. Random write speeds for all three samples were more than one standard deviation above average, with the lowest score putting it in the 90th percentile. Random read scores for two of the three were more than one standard deviation above average, with the lowest score putting it in the 72nd percentile. However, this card did poorly in sequential write speeds — while less than one standard deviation below average, the highest measurement put it in the 28th percentile.
Sample #1 endured 2,568 read/write cycles before failing — making it past the 2,000 read/write cycle minimum that I’ve established. The test ended when the card made itself read-only; stressdisk did not note any data mismatch errors prior to that point. I have to wonder if this was an intended behavior, or if some other issue occurred that caused the card to make itself read-only. If it was an intended behavior, it would be useful in that it would give a user the opportunity to retrieve their data off of a failing card before it failed completely.
Samples #2-#4 are currently undergoing endurance testing:
- Sample #2 has not yet made it to the 2,000 read/write cycle mark. It is currently expected to reach this point sometime in February 2025.
- Sample #3 has survived 3,298 read/write cycles so far.
- Sample #4’s first error was a single bit flip, in a single sector, during round 924. It has survived 2,390 read/write cycles in total so far.
On a side note, I want to say that I love Kioxia’s packaging — more specifically, the outer packaging. It’s tamper-evident and it’s easy to open. I wish more manufacturers would make their packaging so easy. The inner packaging is another story — it’s a plastic clamshell with a thin layer of plastic on the back that you have to peel back to get to the card. This layer takes a little bit of effort to start peeling, and it tears easily — however, if this happens, a utility knife will make short work of it.
September 10, 2024 (current number of read/write cycles is updated automatically every hour)
Kioxia Exceria G2 64GB
- Obtained from: AliExpress
- Price paid: $4.79*
- Advertised capacity: 64GB
- Logical capacity: 61,891,149,824 bytes
- Physical capacity: 61,891,149,824 bytes
- Fake/skimpy flash: Skimpy (3.30% skimp)
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: Class 10, U30, V30, A1
- CID data:
- Manufacturer ID:
0x02
** - OEM ID:
0x544d
(ASCII:TM
)** - Product name:
0x5345303634
(ASCII:SE064
) - Product revision:
0x89
- Manufacturer ID:
* The price shown is for the 32GB version. See the discussion for more information.
** This manufacturer ID/OEM ID is well known to be associated with Toshiba/Kioxia.
Discussion
First things first — I actually ordered the 32GB version; the seller sent me the 64GB version. I don’t know if the seller simply made a mistake or if they were out of the 32GB version and sent me the 64GB as a replacement — but whatever. Free upgrade!
Performance-wise, these cards actually did rather well. All three cards had sequential write speeds that were more than one standard deviation above average, with the lowest measurement putting it in the 84th percentile. Sample #1 had a random read speed that was more than two standard deviations above average, and a random write speed that was more than one standard deviation above average. The lowest of the random read speeds put it in the 75th percentile, while the lowest of the random write speeds put it in the 81st percentile.
As of this writing, all three cards are still undergoing endurance testing:
- Sample #1 has experienced errors, but it made it well past the 2,000 read/write cycle mark before doing so — its first error was during round 5,110, and it has survived 8,059 read/write cycles overall so far.
- Sample #2 survived 895 read/write cycles before it experienced a data mismatch error; however, the error only affected 8 sectors and has not recurred since. It has survived 5,897 read/write cycles so far.
- Sample #3 has survived 5,091 read/write cycles so far and has not yet experienced any errors.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Kioxia Exceria Plus 32GB
- Obtained from: AliExpress
- Price paid: $8.19
- Advertised capacity: 32GB
- Logical capacity: 30,937,186,304 bytes
- Physical capacity: 30,937,186,304 bytes
- Fake/skimpy flash: Skimpy (3.32% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 3.06%
- Speed class markings: Class 10*, U3, V30, A1*
- CID data:
- Manufacturer ID:
0x02
** - OEM ID:
0x544d
(ASCII:TM
)** - Product name:
0x5545304441
(ASCII:UE0DA
) - Product revision:
0x71
- Manufacturer ID:
* The Class 10 and A1 markings appear on the product packaging, but do not appear on the card.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with Toshiba/Kioxia.
Discussion
The Kioxia Exceria G2’s performed well in all of the performance tests, which made me curious to see what else Kioxia had to offer.
I was a little surprised to see this card set a new record for skimp in a non-fake flash card, coming at 3.32% — beating out the previous contender, the Kioxia Exceria G2, at 3.30%. I was also a little surprised to see it perform worse in all performance metrics than the Kioxia Exceria G2. It did, however, perform above average in sequential write and random write speeds, but only average in sequential read speeds and below average in random read speeds.
The card bears the U3 and V30 marks, and performance was enough to qualify for these marks. The package also bears the Class 10 and A1 marks; and while performance was good enough to qualify for the Class 10 mark, it wasn’t good enough to qualify for the A1 mark. Interestingly, most other cards that bear the A1 mark have less trouble meeting the threshold for random read operations, and more trouble meeting the threshold for random write operations. This card was the opposite: sample #2 met the 500 random write operations per second threshold, sample #1 came within 3% of that threshold, and sample #3 came just 0.01% short. Random read scores, on the other hand, were farther off the mark.
Endurance tests for these cards are still ongoing:
- Sample #1’s first error was a four-sector wide address decoding error during round 2,319. It has survived 6,049 read/write cycles in total so far.
- Sample #2’s first error was a 1,568-sector wide data verification error during round 2,315; it has survived 5,863 read/write cycles in total so far.
- Sample #3’s first error was a four-sector wide address decoding error during round 1,612; it has survived 5,839 read/write cycles in total so far.
Overall, this seems to be a decent card. It suffers in read speeds, but it makes up for it by delivering superior write speeds. However, the Kioxia Exceria G2 scored better in all metrics that I measured — and was almost half the price. If I had to choose between the two in the future, I’d definitely go for the G2 over this one.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Kodak Ultra Performance 32GB
- Advertised capacity: 32GB
- Logical capacity: 31,164,727,296 bytes
- Physical capacity: 31,164,727,296 bytes
- Fake/skimpy flash: Skimpy (2.61% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 2.35%
- Speed class markings: Class 10, U3, V30, A1
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x3030303030
(ASCII:00000
) - Product revision:
0x00
- Manufacturer ID:
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $7.47 | $1.79 | $1.79 | $3.68 |
Serial number | 0xb8201f91 | 0xba100caa | 0xbb4010e4 | N/A |
Manufacture date | Jun 2023 | Jun 2023 | Jun 2023 | N/A |
Sequential read speed (MB/sec) | 88.95 | 83.97 | 83.37 | 85.43 |
Sequential write speed (MB/sec) | 13.43 | 14.27 | 15.86 | 14.52 |
Random read speed (IOPS/sec) | 1,709.83 | 1,663.23 | 1,506.21 | 1,626.42 |
Random write speed (IOPS/sec) | 187.58 | 171.76 | 169.81 | 176.38 |
Read/write cycles to first error | 3,530 | Not yet determined | Not yet determined | 3,530 |
Read/write cycles to complete failure | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
Total days to complete failure | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
Card reader used | SmartQ Single* | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | N/A | |||
Package back | Not available | Not available | N/A | |
Card front | N/A | |||
Card back | N/A |
* I think.
Discussion
When I started this project, I searched for SD cards on AliExpress, then sorted the results in ascending order by price. I believe this is one came up as one of the early results. The price point was a little more than I wanted to pay — which is why I only ordered one of them initially. (I later decided to try to get 3 of each model, which is why I ordered the other two.) I’ll note that many of the results manipulated their position in the search results by including a variation of the product which was simply a microSD-to-SD adapter, which the sellers can afford to sell for a much lower price than the cards themselves — and which appears as the price for the item in the search results. This is the case on this item as of the time of this writing (with them listing a microSD-to-SD adapter for $0.56, excluding shipping), and I believe it was the case at the time I purchased it.
Performance-wise, this card was disappointing:
- Sequential read scores for all three samples were less than 0.5 standard deviations above average. The worst measurement in this category put it into the 41st percentile.
- Sequential write scores for all three samples were below average, with sample #1 scoring one standard deviation below average. The worst measurement in this category put it into the 16th percentile.
- Random read scores for all three samples were less than 0.5 standard deviations below average. The worst measurement in this category put it into the 42nd percentile.
- Random write scores for all three samples were less than 1 standard deviation below average. The worst measurement in this category put it into the 22nd percentile.
- All samples performed well enough to merit the Class 10 marking that it bears, but not well enough for any of the others. Perhaps they would have done better if they had been tested under proper test conditions…but somehow I doubt it.
Curiously, the 32GB and 64GB versions appear to have been made by different manufacturers, as indicated by the data in their respective CID registers. The 64GB version did markedly better on write performance — although, interestingly, markedly worse on read performance. Both versions are similar in their packaging — although the 64GB version came with a microSD-to-SD adapter, whereas the 32GB version did not — and both bear the information of Dexxon Groupe, indicating (to me, at least) that they were likely sold by Dexxon under license from Kodak. Indeed, their website indicates that they sell storage and IT products for a number of various well-known brands, Kodak included. It appears that Dexxon simply chose different manufacturers for the two versions of this card. It’s unclear exactly what the reason for this is.
As of this writing, all three samples are still undergoing endurance testing:
- Sample #1’s first error was a 6-sector wide data verification error during round 3,531. It has survived 6,671 read/write cycles so far.
- Sample #2 has survived 2,676 read/write cycles so far and has not yet experienced any errors.
- Sample #3 has survived 2,675 read/write cycles so far and has not yet experienced any errors.
September 2, 2024 (current number of read/write cycles is updated automatically every hour)
Kodak Ultra Performance 64GB
- Advertised capacity: 64GB
- Fake/skimpy flash: Skimpy (2.26% skimp)
- Protected area: 134,217,728 bytes
- Speed class markings: Class 10, U3, V30, A1
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0303
- Product name:
0x5344414243
(ASCII:SDABC
) - Product revision:
0x10
- Manufacturer ID:
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Logical capacity | 62,552,276,992 bytes | 62,544,412,672 bytes | 62,544,412,672 bytes | 62,547,034,112 bytes |
Physical capacity | 62,552,276,992 bytes | 62,544,412,672 bytes | 62,544,412,672 bytes | 62,547,034,112 bytes |
Fake/skimpy flash | Skimpy (2.26% skimp) | Skimpy (2.27% skimp) | Skimpy (2.27% skimp) | N/A |
Adjusted skimp | 2.05% | 2.06% | 2.06% | 2.06% |
Price paid | $4.16 | $1.79 | $1.79 | $2.58 |
Manufacture date | Feb 2023 | Jun 2023 | Jun 2023 | N/A |
Serial number | 0xaa000c38 | 0xaa000aeb | 0xaa0002fb | N/A |
Sequential read speed (MB/sec) | 51.79 | 89.87 | 89.60 | 77.09 |
Sequential write speed (MB/sec) | 34.63 | 39.32 | 36.85 | 36.93 |
Random read speed (IOPS/sec) | 2,559.74 | 1,872.58 | 1,814.41 | 2,082.24 |
Random write speed (IOPS/sec) | 554.12 | 471.09 | 452.61 | 492.61 |
Read/write cycles to first error | 2,518 | 219 | 728 | 1,155 |
Read/write cycles to complete failure | 4,240 | Not yet determined | Not yet determined | 4,240 |
Total days to complete failure | 239 | Not yet determined | Not yet determined | 239 |
Card reader used | SmartQ Duo | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | N/A | |||
Package back | N/A | |||
Card front | N/A | |||
Card back | N/A |
Discussion
I believe that I found this item as a result of recommendations that AliExpress made while I was looking at the Kodak Ultra Performance 32GB card above. Curiously, they were being sold by different sellers — sample #1 of the 32GB card was being sold by “Kodak Store”, while sample #1 of the 64GB card was being sold by “Kodak Global Store”. As I noted above, the two versions also have different manufacturer IDs; however, I’m not convinced that these two facts are related to each other. Additionally, astute readers will note that sample #1 was actually cheaper than sample #1 of the 32GB version. This card was sold with free shipping, while the 32GB card was not; however, even before shipping costs, the 64GB card was still cheaper — as I paid $4.16 for it, and $5.00 for the 32GB version (before shipping). This price was still above what I wanted to pay at the time, however, so I initially only ordered one of them. (I later decided that I should try to have at least three of each model, and I managed to get them through one of AliExpress’s sales.)
Sequential read speeds on sample #1 was disappointing, but samples #2 and #3 were able to make up for it. All other performance metrics were above average for all three samples, with random read speeds for sample #1 being more than one standard deviation above average. Sample #1 met the requirements for all of the speed class markings that it bore; however, samples #2 and #3 fell short of the 500 random write operations per second needed to qualify for the A1 marking. They got close enough, however, that my standard disclaimer of “these cards may have done better had they been tested under proper conditions” might actually be true.
On the endurance front, sample #1 made it past the 2,000 read/write cycle mark without errors. It experienced its first error during round 2,518.* It also experienced a couple of bit-flip errors affecting two sectors during round 3,903. It finally started experiencing a large number of data loss errors starting in round 4,215; by the end of round 4,241, those errors had affected over 50% of the sectors on the device.
The graph for this card looks pretty boring — but nevertheless, here it is:
Samples #2’s first error was a four-sector wide address decoding error during round 219. It has survived 2,626 read/write cycles in total so far.
Sample #3’s first error was a four-sector wide address decoding error that occurred during round 729. It has also survived 2,612 read/write cycles so far.
* This error may have been related to the fact that I pulled it from its reader during testing so that I could read the registers off of it with the Realtek reader. However, my program was well into the readback portion of the round when I pulled it — and section 4.3.3 of the SD Physical Layer Specification says that “[t]he read operation from SD memory card may be interrupted by turning the power off. The SD Memory Card ensures that data is not destroyed during all the conditions except write or erase operations issued by the host even in the event of sudden shut down or removal.” Given that my program was only issuing read operations, any data in the card’s cache should have long since been written out to flash. Regardless, the symptoms do seem to be consistent with a cached write that was only partially flushed.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
"Lenovo" 128GB
- Obtained from: AliExpress
- Advertised capacity: 128GB
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: None
Discussion
This is one I found while browsing randomly through AliExpress, and one I heavily suspected would be fake flash when I ordered it. I was curious to see whether lower and higher capacity models would both be fake flash, or if these sellers would limit their fake flash to just higher capacity models — so I bought a single 128GB card (which was the lowest capacity they offered) and a single 2TB card. Later, after I made the decision to test at least three samples of each brand/model/capacity, I went back and ordered two more. Unfortunately, the seller sent me 256GB cards, so I had to order another two from a different seller. Spoiler: they’re all fake flash.
Disclaimer: I don’t think Lenovo had anything to do with this card. I think this is an unlicensed knock-off (hence why “Lenovo” is in quotes).
I’ve noticed a number of trends with some (though not all) fake flash. For example, many fake flash cards bear the name of well-known electronics manufacturer, even though the manufacturer is not known for selling SD cards. (For example, I’ve obtained cards bearing the names of Lenovo, Sony, and Xiaomi.) Most of them — or at least, the ones I’ve been able to read the CID data from — have had their manufacturer ID set to 0x00
and their OEM ID set to 0x0000
, presumably to hide the identity of their manufacturer. Additionally, these cards also tend to have pretty abysmal performance across the board. This card is no exception: all performance results have been below average, with most results being more than one standard deviation below average.
This particular seller also attempted to be sneaky by not including any of the standard speed class marks. Instead, they opted to include the Nintendo Switch icon instead — which, last I checked, wasn’t an indicator of speed. (They did include the UHS-I mark, but this mark by itself also doesn’t make any assertions as to the card’s read or write speeds.)
Sample #1 chugged along on its endurance test for quite some time; however, it only managed to go 327 read/write cycles before starting to display data mismatch errors. At first, the errors only affected two sectors; however, the number of sectors increased nearly every round after that. (Almost all of these errors have been bit-flip errors.)
This eventually caused problems for my code’s device detection logic: the program keeps a copy of the data that it wrote to two fixed segments on the card. When a device is disconnected and reconnected, or when the program is interrupted and restarted, it tries to automatically identify which device it was testing, and it reads back the contents of both of those segments as part of that process. However, this card had so many sectors go bad that both of those segments quickly became unstable. When an issue occurred, I had to restart the endurance test from scratch.
Sample #1 spent most of its endurance test in one of the SanDisk MobileMate readers. However, as a JJS CR-UTC4AC reader became available, I moved it to one of those readers. This, of course, necessitated the restart of the endurance test. Strangely, on the first round of the endurance test, large portions of the card that had been marked as bad in other tests passed verification; however, the remainder of the card failed verification. At this point, over 50% of the sectors on the card had been flagged as bad, and the endurance test was ended.
Sample #2’s first error was a bit flip error that affected two sectors during round 999. It kept going for a while — continuing to experience a number of bit flips, but managing to stay under the 1% failure threshold — right up until round 2,083. In that round, every single sector that it read from the device came back as all 0xff
‘s — at which point the card was declared dead (since it reached the 50% error threshold). Here’s the graph of this card’s progression:
Sample #3’s first error was a bit flip error that affected two sectors during round 1,632. It managed to go for about another 730 read/write cycles before it hit the 0.1% threshold. But then, during round 2,534, all sectors started reading as 0xff
‘s — and at that point, the test was over.
August 12, 2024
"Lenovo" 256GB
- Obtained from: AliExpress
- Advertised capacity: 256GB
- Logical capacity: 268,435,456,000 bytes
- Physical capacity: 31,434,108,416 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: None
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x4150505344
(ASCII:APPSD
) - Product revision:
0x00
- Manufacturer ID:
Discussion
Ok, let’s be clear: I didn’t want to test this card. I had already one of the 128GB and one of the 2TB variants of this card and knew that they were fake and performed poorly. However, my decision to test at least three samples of each card came back to bite me in the ass here: when I ordered two more of these cards, the seller actually sent me two 256GB cards instead.
Well crap.
So…I went to a different seller and got two 128GB cards. But what to do with these cards? I know they’re fake. I know I have no use for them outside of this project. Might as well get a third one and add it to my test set.
I found the ASUZIO CAZE through random internet searches and wanted to try it out, so I decided to use sample #1 as a test case for this card. The only thing that stood out about this card — compared to the other Lenovo’s I’ve tested to date — is that it got slower sequential read and random write speeds than any of the others. But aside from that, it’s a pretty unremarkable knockoff fake flash card.
Sample #1 is still undergoing endurance testing. Its first error was a series of bit flips, affecting four sectors, during round 378. As of the time of this writing, it has completed 413 read/write cycles — however, I don’t expect it to last too much longer, as it’s been experiencing I/O errors for quite some time and has been stuck on the same round of testing for the last two weeks.
Samples #2 and #3 are still in the package waiting to be tested.
September 15, 2024
"Lenovo" 2TB
- Obtained from: AliExpress
- Advertised capacity: 2TB
- Logical capacity: 2,147,483,648,000 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: None
Discussion
As with the 128GB above, I wanted to get a card that was obviously fake flash and one that could have been ambiguous to see if only one would be fake, or if they would both be fake. It turns out they were both fake. (I later purchased two additional samples after deciding that I should try to have at least three samples of each model that I’m testing.)
Disclaimer: I don’t believe Lenovo had anything to do with this card. I think this is an unlicensed knock-off — hence why “Lenovo” is in quotes.
This card continues the fake flash trend of terrible performance. While it did better on the sequential write and random write tests than its 128GB sibling, it did about the same on the sequential read and random read tests. With the exception of the random read scores for samples #2 and #3, all results were below average — and even those two barely made it above average. Sequential read scores for all three samples were more than one standard deviation below average, with the worst score of the three putting it in the 14th percentile. As with the 128GB card, the seller only put the UHS-I mark on this card — there are no speed class marks to evaluate for.
On the endurance front, sample #1 endured far better than its 128GB sibling: it completed 5,601 read/write cycles before showing any errors. Curiously, when data mismatch errors occurred, they were mostly happening as a single group of 64 contiguous sectors — with the data read not at all seeming to resemble the data written — which are then separated by a number of read/write cycles where no data mismatch errors occur. The number of rounds between data mismatch errors seemed to be random, ranging from as few as 5 to as many as 625. This implies to me that the card was employing some sort of wear leveling (probably dynamic wear leveling), the bad sectors weren’t being detected by the card, and the card was simply recycling the bad sectors as part of its wear leveling algorithm.
During round 11,626, it started experiencing a number of missing data errors; however, the number of sectors affected during this round — as well as the next 5 rounds — represented only a fraction of a percent of the total sectors on the device. However, this escalated during round 11,632 — during this round, the total number of bad sectors on the device went from 0.126% to 3.52%. By the end of round 11,633, that number shot up 43.089%. Sometime during round 11,634, the card stopped responding to commands altogether, and the endurance test was considered complete at that point.
Samples #2 and #3 are still going through endurance testing:
- Sample #2 has survived 7,756 read/write cycles and has not yet experienced any errors.
- Sample #3’s first error was a series of bit flips, affecting two contiguous sectors, during round 8,311. It has survived 10,312 read/write cycles in total so far.
September 16, 2024 (current number of read/write cycles is updated automatically every hour)
Lenovo thinkplus 256GB
- Obtained from: AliExpress
- Price paid: $9.99
- Advertised capacity: 256GB
- Logical capacity: 250,139,901,952 bytes
- Physical capacity: 250,139,901,952 bytes
- Fake/skimpy flash: Skimpy (2.29% skimp)
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: Class 10, U3, V30, A2
- CID data:
- Manufacturer ID:
0xdf
- OEM ID:
0x2306
- Product name:
0x5344323536
(ASCII:SD256
) - Product revision:
0x20
- Manufacturer ID:
Discussion
While cruising through deals on AliExpress, I came upon this model. While I was not entirely convinced that it wasn’t fake, it seems like the seller did try a little harder to pass this off as genuine than some of the other options I’ve come across — so I decided to give it a try.
The packaging for this card looks more like what I’d expect from a name-brand card. Branding is present and on-point, color schemes match the brand’s color scheme, the card’s capacity is printed on the packaging, there are disclaimers printed on the package about the definitions of a kilobyte/megabyte/gigabyte, and there is contact information printed on the package. While none of these factors individually would be enough to convince me that a product is genuine, the combination of all of them tells me that this product is — dare I say — most likely genuine.
So far, this actually seems to be a decent card — not a great card, but not a terrible card either. I was pleased to see that it was not fake flash, and at $0.04 per gigabyte, it’s starting to rival the price for platter-based drives. (For comparison, a new WD Blue 3.5″ mechanical drive runs between $0.016 and $0.045 per gigabyte, at the time of this writing, depending on which capacity you buy.) Additionally, all performance metrics were within one standard deviation from average — with sequential I/O speeds being above average, and random I/O speeds being below average. Of the speed class markings that it bears, it performed well enough to qualify for all of them except for the A2 marking. I’ll give my standard disclaimer — perhaps it would have done better if it had been tested under proper conditions — but the A2 mark requires a random write performance of 2,000 IOPS per second, and these cards only made it about 15% of the way there. I seriously doubt it would have done significantly better had it been tested with a reader that offered the capabilities needed to test it properly.
All three samples are currently undergoing endurance testing:
- Sample #1’s first error was a six-sector wide address decoding error during round 247. It has survived 588 read/write cycles in total so far.
- Sample #2’s first error was an eight-sector wide address decoding error during round 309. It has survived 595 read/write cycles in total so far.
- Sample #3’s first error was a two-sector wide address decoding error during round 321. It has survived 609 read/write cycles in total so far.
Side note: samples #1 and #2 did technically experience errors earlier on, but I’m almost positive that they were device mangling errors and thus not the card’s fault. Therefore, I’ve decided to discard those errors.
August 8, 2024
Lexar Blue 633x 32GB
- Obtained from: AliExpress
- Price paid: $1.99
- Advertised capacity: 32GB
- Logical capacity: 31,719,424,000 bytes
- Physical capacity: 31,719,424,000 bytes
- Fake/skimpy flash: Skimpy (0.88% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.61%
- Speed class markings: Class 10*, U1, V10, A1
- CID data:
- Manufacturer ID:
0xad
- OEM ID:
0x4c53
(ASCII:LS
) - Product name:
0x4c58333247
(ASCII:LX32G
) - Product revision:
0x10
- Manufacturer ID:
Discussion
By mid-January 2024, I had started endurance testing on two of the Lexar Professional 1000x 64GB cards, and it became obvious that these cards had a pretty significant data integrity issue (see the discussion on those cards for more info). However, seeing as those were the only Lexar cards in my collection, I thought that it would be a pretty poor representation of Lexar as a whole — so I decided it would be good to include another Lexar model.
There’s one particular data point that strikes me as odd: the manufacturer ID. None of the sources I looked at listed manufacturer ID 0xad
as belonging to Lexar — or anyone at all. This manufacturer ID is shared by two other brands in my collection: Chuxia and OV. In fact, all three not only had the same manufacturer ID, but also the same OEM ID. This could be a sign that these cards were fake; however, I didn’t see any other signs indicating that the card is fake — capacity is as advertised, and printing (on both the card and the packaging) was clear and high quality. The markings on the back of the card appear to have been printed on — as opposed the Lexar Professional 1000x 64GB, where it appears the markings were laser-etched — but this is about the only inconsistency I could spot off the bat. If this is a fake, it’s a pretty convincing fake.
However, I think there’s a more mundane explanation. The Lexar Professional 1000x 64GB cards have manufacture dates of Jan 2017 and Feb 2017, while these cards have a manufacture date of Aug 2023. Lexar was owned by Micron up until August of 2017, when they made the decision to sell the Lexar brand name to Shenzhen Longsys Electronics Co. — meaning that the two Lexar Professional 1000x 64GB cards would have been made by Micron, and these two would have been made by Longsys. Given that, I think manufacturer ID 0xad
is probably assigned to Longsys.
Performance-wise, these cards did above average in all categories except sequential write speeds, which were slightly below average. The worst of the sequential write scores put this card in the 50th percentile for this category. However, random write speeds — a category which a lot of cards struggled with — were more than one standard deviation above average, with the worst of the three scores putting it in the 84th percentile. These cards easily surpassed the thresholds for all of the speed class marks that they bore. Honestly — not bad for a card that was only $1.99.
All three samples are still undergoing endurance testing:
- Sample #1’s first error was an address decoding error during round 158; it has survived 8,395 read/write cycles so far.
- Sample #2’s first error was an address decoding error during round 268; it has survived 4,893 read/write cycles so far.
- Sample #3 was the only one of the three that managed to survive for at least 2,000 read/write cycles before experiencing its first error, which was — you guessed it — an address decoding error during round 2,058. It has survived 6,184 read/write cycles so far.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Lexar Professional 1000x 64GB
- Obtained from: Amazon
- Advertised capacity: 64GB
- Fake/skimpy flash: No
- Protected area: 134,217,728 bytes
- Speed class markings: Class 10, U3
* This manufacturer ID/OEM ID combination is pretty well known to be associated with Lexar.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with Phison.
Discussion
Oh boy, do I have a thing or two to say about these cards. So here we go.
I purchased sample #1 because I wanted to be able to have at least one UHS-II card in my results. UHS-II cards tend to be pretty expensive (comparatively speaking), which is why I initially only ordered one. It came in retail packaging, complete with a Lexar LRWM05U-7000 UHS-II card reader, and I initially planned to test it with this card reader — but fate (or Lexar?) apparently had other ideas. It almost immediately had issues, unable to make it through even its authenticity or performance tests. After a few tries, I was able to get it to complete both tests — but I found that it was much more stable when I switched it over to another reader, so I gave up on the Lexar LRWM05U-7000 and put it into a JJS CR-UTC4AC instead.
I bought the first of these cards because I wanted to be able to have at least one UHS-II card in my results. UHS-II cards tend to be pretty expensive (comparatively speaking), so I initially only ordered one. It arrived in retail packaging, which included a Lexar LRWM05U-7000 UHS-II card reader. I planned to test it using this card reader; however, it started to experience I/O errors soon after tests began. On the next attempt, I was able to get it to complete its authenticity and performance tests; but it then started experiencing I/O errors during the first round of endurance testing. Restarting the endurance test didn’t seem to help — so I decided to move it to one of the JJS CR-UTC4ACs instead.
The I/O errors stopped under the JJS reader, but then a different issue surfaced: in every round of the endurance test, there would be a handful of data verification failures. But when I looked at the data being read back and compared it to what was being written to the card, I noticed something odd. Here’s a snippet of my logs — see if you can spot the issue:
[Sat Nov 11 02:19:40 2023] 00000009e2a70200: 3e 78 78 ef e5 e9 fe cc 42 60 17 ae b7 6a 4f a6
[Sat Nov 11 02:19:40 2023] 00000009e2a70210: dd d6 24 cc 5c 53 f0 f4 16 47 f8 e5 80 04 47 df
[Sat Nov 11 02:19:40 2023] 00000009e2a70220: 51 9b cc 84 03 85 8e f0 aa c5 2a d4 72 c7 35 97
[Sat Nov 11 02:19:40 2023] 00000009e2a70230: af e9 18 b3 7d ad 77 a4 5b 31 f4 fe d1 e0 75 e2
...
[Sat Nov 11 02:19:40 2023] Actual data was:
[Sat Nov 11 02:19:40 2023] 00000009e2a70200: 3e 78 78 ef e5 e9 fe cc 42 60 17 ae b7 6a 4f a6
[Sat Nov 11 02:19:40 2023] 00000009e2a70210: 7f 45 ea b4 5c 53 f0 f4 16 47 f8 e5 80 04 47 df
[Sat Nov 11 02:19:40 2023] 00000009e2a70220: 51 9b cc 84 03 85 8e f0 aa c5 2a d4 72 c7 35 97
[Sat Nov 11 02:19:40 2023] 00000009e2a70230: af e9 18 b3 7d ad 77 a4 5b 31 f4 fe d1 e0 75 e2
...
And another mismatch that happened a couple weeks later:
[Wed Nov 29 05:10:17 2023] 000000034dafc200: db cb 0e bb 8e 05 2b b4 c0 80 c0 f9 5e ca 84 bd
[Wed Nov 29 05:10:17 2023] 000000034dafc210: 38 88 89 c0 8f 4c eb c9 43 1a df b9 fc 8a 84 df
[Wed Nov 29 05:10:17 2023] 000000034dafc220: 39 e2 88 ce fc 87 4d a9 11 e9 70 be eb 85 53 8e
[Wed Nov 29 05:10:17 2023] 000000034dafc230: 20 8a 3d c2 03 5b ee e4 cd f2 ed ac 55 1a 70 aa
...
[Wed Nov 29 05:10:17 2023] Actual data was:
[Wed Nov 29 05:10:17 2023] 000000034dafc200: db cb 0e bb 8e 05 2b b4 c0 80 c0 f9 5e ca 84 bd
[Wed Nov 29 05:10:17 2023] 000000034dafc210: f6 19 bb eb 8f 4c eb c9 43 1a df b9 fc 8a 84 df
[Wed Nov 29 05:10:17 2023] 000000034dafc220: 39 e2 88 ce fc 87 4d a9 11 e9 70 be eb 85 53 8e
[Wed Nov 29 05:10:17 2023] 000000034dafc230: 20 8a 3d c2 03 5b ee e4 cd f2 ed ac 55 1a 70 aa
...
See that? It’s always bytes 16-19 that are mismatched. Every. Single. Time.
“OK”, I thought to myself, “maybe I just got a bad card. It happens. I’ll just order another one.” So I did, and from the same Amazon seller. This one looked pretty much identical to the first one, complete with another Lexar LRWM05U-7000 card reader. This time, I decided to set that one aside, and I put it straight into one of the JJS CR-UTC4AC readers. And as soon as the endurance test started running? It started having the same issue — right down to the same four bytes being mismatched:
[Mon Nov 20 20:36:07 2023] 00000001e4b04200: 2c 7d 0a a6 e0 d2 23 8f b6 9b f3 0a 44 f8 6b a2
[Mon Nov 20 20:36:07 2023] 00000001e4b04210: 9c 4e d8 fe 8e 51 ae 43 b1 62 fe b8 aa 3d 6c 77
[Mon Nov 20 20:36:07 2023] 00000001e4b04220: 39 f8 4f 95 15 43 c2 9d 8f f6 5b 82 57 32 85 e4
[Mon Nov 20 20:36:07 2023] 00000001e4b04230: 09 79 d8 bb 17 70 11 ff 68 97 be 96 a3 d9 c5 8d
...
[Mon Nov 20 20:36:07 2023] Actual data was:
[Mon Nov 20 20:36:07 2023] 00000001e4b04200: 2c 7d 0a a6 e0 d2 23 8f b6 9b f3 0a 44 f8 6b a2
[Mon Nov 20 20:36:07 2023] 00000001e4b04210: 61 1a 0b 86 8e 51 ae 43 b1 62 fe b8 aa 3d 6c 77
[Mon Nov 20 20:36:07 2023] 00000001e4b04220: 39 f8 4f 95 15 43 c2 9d 8f f6 5b 82 57 32 85 e4
[Mon Nov 20 20:36:07 2023] 00000001e4b04230: 09 79 d8 bb 17 70 11 ff 68 97 be 96 a3 d9 c5 8d
...
This was too weird to be coincidence. I considered that maybe they were both part of the same batch, and that there was an issue with that particular batch — but the two cards have different manufacturing dates (and wildly different serial numbers). That means that either there was a manufacturing issue that went undetected for multiple batches, or there’s a design flaw with this card.
For a while, I was going to leave it at that; but at some point, I decided that I should try to have at least three samples of all the cards I’m testing — so I went back to the same Amazon seller and ordered a third one. Here’s where the story took a twist: the product packaging was identical, it included another Lexar LRWM05U-7000 card reader, the card design was the same — but the CID data indicates that it’s a completely different card! Every single field in the CID register was different from the other two samples. The manufacturer ID indicates that it was made by Phison — which has been known to make Lexar-branded cards in the past (at least, according to CameraMemorySpeed.com) — so my guess is that Lexar simply contracted out part of the production of these cards to Phison.
The package advertises read speeds of up to 150MB/sec and write speeds of up to 45MB/sec. All three samples managed to surpass 150MB/sec on sequential read speeds (putting it more than one standard deviation above average, with two of the samples scoring more than two standard deviations above average), but only sample #3 (the Phison-produced sample) managed to hit the 45MB/sec mark on sequential write speeds. Samples #1 and #2 ended up being just slightly above average in this category, while sample #3 ended up being more than one standard deviation above average.
Random I/O speeds were pretty inconsistent. When tested with the Lexar LRWM05U-7000, sample #1 got random read speeds that were more than one standard deviation above average. However, the same card, tested on the same machine with a JJS CR-UTC4AC, only managed to get about 1/4 of that. Both random read speeds and random write speeds ran the gamut from “well below average” to “more than one standard deviation above average”, depending on the card. I can’t say for sure whether the Phison-produced samples or the Lexar-produced samples were better for random read speeds, but it did seem like the Phison-produced sample was significantly better for random write speeds.
All three samples scored well enough to merit the Class 10 and U3 markings; but frankly, I would have expected better for a name-brand card that had “Professional” as part of its name — especially when there are UHS-I cards that were able to perform better.
All three samples are still undergoing endurance testing:
- Sample #1 has survived 3,812 read/write cycles so far.
- Sample #2 has survived 4,822 read/write cycles so far. (I find it curious that sample #2 has outpaced sample #1 — they’re both hooked up to the same machine, to identical card readers. However, sample #1 is averaging about 9.14 read/write cycles per day, while sample #2 is averaging about 14.85 read/write cycles per day. I don’t know why.)
- Sample #3 has survived 3,032 read/write cycles so far.
Of course, there’s one more strangeness to add to this whole thing: by round 294, the errors with sample #1 stopped completely, and did not recur until round 988. Did the card’s wear leveling algorithm simply rotate these bad sectors out into its spare space for those intervening 700-ish rounds? Or was some other factor at work here? (It’s times like these that make me wish I could see into what’s going on inside the microSD card…) Meanwhile, sample #2 is still turning up a handful of errors almost every round.
The Phison-produced sample, on the other hand, has not had quite the same issues that the Lexar-produced samples did. This sample managed to go 163 read/write cycles before its first error — a four-sector wide address decoding error. It experienced another address decoding error — this time affecting six sectors — during round 173, but has not experienced any further errors since then.
Overall, however, I wouldn’t recommend buying this card. While some of the performance metrics were good-to-impressive, it doesn’t make up for the data integrity issues that I encountered on the two Lexar-produced samples. As evidenced by the fact that I bought all three samples from the same seller and got two different cards, I think it’s fair to say that if you purchased one of these, there would be no way of knowing beforehand whether you were going to get a Lexar-produced card or a Phison-produced card. Had I used this in a digital camera and gone on a photo shoot, it’s likely that some of my pictures would have been corrupted the very first time I used the card — and any photographer will tell you that’s just not acceptable.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Microdrive "Bart Simpson" 16GB
- Obtained from: AliExpress
- Price paid: $2.89
- Advertised capacity: 16GB
- Protected area: 134,217,728 bytes
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0303
- Product name:
0x5344414243
(ASCII:SDABC
) - Product revision:
0x10
- Manufacturer ID:
Discussion
This is a card that I bought during my first round of SD card purchases from AliExpress, and I very clearly remember the thing that stood out to me about these cards: Bart Simpson peeking in from the side of the card. I’m sure Fox would love to hear about this.
Now, a disclaimer: I think these were sold by Microdrive, but I’m not 100% certain. For the longest time, I had these in my list as simply “Unbranded Simpsons card” because I wasn’t 100% sure they were Microdrive cards. The card itself doesn’t have any brand name on it, and neither does the package it came in — it came in a generic red package that had no brand name, no indication of the size of the card in the package, no speed markings, and no manufacturer information. It’s substantially identical to the packaging that several other off-brand/knockoff/fake cards came in. (What’s funny to me is that the package has a telephone icon that says “tech support” above it, but there’s no indication of where to go to get said tech support — there are no websites, no phone numbers, no mailing addresses…nothing.) However, these cards came from an AliExpress store called “MD Factory Promotional Store”, and many of the other products they sell are Microdrive branded — so I’m choosing to believe that these cards were made by Microdrive as well.
Curiously, sample #2’s CID data indicated a manufacturing date of January 2013 — which would have been more than 10 years before I purchased it — while samples #1 and #3 had more recent dates of May 2023 and June 2023, respectively. When I noticed this, I went back and re-read the CID from the card to make sure I hadn’t made a mistake (such as transcribing the CID value to my spreadsheet by hand and mistyping something) — but alas, I had it correct the first time. Given that sample #2’s packaging didn’t make it look like it had been sitting around for 10 years, I’m inclined to think that its manufacture date was a mistake, and that it was actually made more recently.
Performance measurements on these cards were pretty inconsistent — but overall, were just “meh”:
- Sequential read speeds ran the gamut from “slightly below average” to “slightly above average”. The worst of the three scores would put it into the 31st percentile, while the best would put it into the 60th percentile.
- Sequential write speeds ran the gamut to “below average” to “more than one standard deviation above average”. The worst of the three scores would put it into the 25th percentile, while the best would put it into the 82nd percentile.
- Random read speeds were clustered more closely together — with all three coming close to average. The worst of the three scores would put it into the 43rd percentile, while the best would put it into the 54th percentile.
- Random write speeds ran the gamut from “below average” to “above average”. The worst of the three scores would put it into the 28th percentile, while the best would put it into the 76th percentile.
These cards carry the U1 and Class 10 markings; performance on all three samples was good enough to qualify for both of these markings.
Endurance-wise — these cards actually did pretty well. All three samples made it past the 2,000 read/write cycle mark without errors, making it only one of three models I’ve tested to do so. Samples #2 and #3 are still going:
Sample #2’s first true* error was a data loss error (where the sectors simply read back as all
ff
‘s), during round 10,758, that affected about 10% of the sectors on the device. It then went another 80 read/write cycles with only a few errors. During round 10,839, however, 76% of the sectors on the device started returning allff
‘s; at that point, the endurance test was declared “complete”.The endurance test graph for this one is going to be pretty boring, but here it is regardless:
* Sample #2 did technically have an error during round 216; however, this was attributable to the code I was using at the time that handles device disconnects and reconnects. This issue has since been fixed.
- Sample #3’s first error was a missing data error that affected around 1.6 million sectors (or about 5.22% of the total sectors on the card) during round 6,974. It has survived 13,004 read/write cycles in total so far.
Overall, I think I’m forced to conclude that these are decent cards. They’re not the best performers in terms of read/write speeds (although sample #3 bucked that trend), but so far they seem to have endured pretty well — sample #1 was the worst performer in this area, and it survived 4,270 before it encountered its first error. Some of the “high endurance” cards I’ve tested have been rated for over 6,000 read/write cycles — so while these cards probably wouldn’t cut it as high endurance cards, they certainly come close (and have fared much better than some other cards I’ve tested).
September 7, 2024 (current number of read/write cycles is updated automatically every hour)
Netac 64GB
- Obtained from: AliExpress
- Price paid: $1.99
- Advertised capacity: 64GB
- Protected area: 134,217,728 bytes
- Speed class markings: C10, U1
- CID data:
- OEM ID:
0x0303
- Product revision:
0x10
- OEM ID:
Discussion
As I mentioned with the Netac PRO 16GB (below), Netac has the rare distinction of being the first card I’ve come across that was significantly bigger than what was advertised. It wasn’t a card that was part of this survey — it was an 8GB card that came with one of my 3D printers, and it turned out to be a 16GB card that was simply partitioned with a single 8GB partition. The fact that I purchased these cards simply reflected my curiosity to see if I could make this happen again (although admittedly, the chances of a manufacturer disguising a 128GB card as a 64GB card are pretty low — but then again, the chances of a manufacturer disguising a 16GB card as an 8GB card are pretty low too, but it would be less expensive to do so). However, this turned into another case study of what happens when you source your microSD cards from multiple manufacturers.
There seems to be a pretty clear difference between samples #1 and #2 and sample #3. The first obvious difference is the back of the package: samples #1 and #2 have a wealth of information, including a seal of authenticity, on the back of the package. However, on sample #3, stickers have been used to cover up all of this information. While the normal product packaging has text that is mostly in Chinese, one of the stickers has text that is completely in English — including a FCC Part 15 disclaimer, the manufacturer’s name and address, and the name and address of the UK and European distributors. This suggests to me that they might have intended to prepare this card for sale in English-speaking regions, including the US and the EU.
The next difference is the difference in the card artwork. Samples #1 and #2 have artwork that is a little darker than sample #3 — although it’s hard to tell from the pictures because samples #1 and #2 have a little bit of color correction applied to them.
The next difference comes when the card is plugged in: samples #1 and #2 have a different manufacturer ID and product name than sample #3. Samples #1 and #2 have a manufacturer ID of 0x6f
and a product name of SDABC
, while sample #3 has a manufacturer ID of 0x89
and a product name of NCard
…wait a second — I’ve seen this before. This is exactly what sample #1 of the Netac PRO 16GB (below) showed after it failed! I’m so confused now. Did sample #3 really come from a different manufacturer, or did it simply come from a manufacturer that has more than one manufacturer ID assigned to them? If they came from different manufacturers, then what’s going on with sample #1 of the Netac PRO 16GB? Did the manufacturer spoof another manufacturer’s manufacturer ID???
Well at any rate, let’s move on to the next obvious difference: performance. There was a definite difference in performance between samples #1 and #2 and sample #3. None of them did particularly well — especially in random I/O speeds — but sample #3 set some new lows: 0th percentile for sequential read speed, 2nd percentile for sequential write speeds, 0th percentile for random read speeds, and 26th percentile for random write speeds. Sequential read speeds, sequential write speeds, and random read speeds were all more than one standard deviation below average. The other two samples fared a little better, but were still pretty terrible: the best single measurement was the sequential write speed from sample #2, and that only put it into the 50th percentile in that category.
Finally, let’s move on to endurance: sample #3 also experienced its first error earlier than the other two. All three are still undergoing endurance testing:
- Samples #1 and #2 have not yet hit the 2,000 read/write cycle mark. They are expected to get there sometime in October 2024.
- Sample #3’s first error was a series of bit flip errors affecting 1,450 sectors during round 4. It has survived 731 read/write cycles in total so far.
June 15, 2024 (current number of read/write cycles is updated automatically every hour)
Netac PRO 16GB
- Obtained from: AliExpress
- Price paid: $1.99
- Advertised capacity: 16GB
- Logical capacity: 15,942,025,216 bytes
- Physical capacity: 15,942,025,216 bytes
- Fake/skimpy flash: Skimpy (0.36% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: -0.48%
- Speed class markings: U1*, V10, A1
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0303
- Product name:
0x4342414453
(ASCII:CBADS
) - Product revision:
0x10
- Manufacturer ID:
* The U1 mark only appears on the card — it does not appear on the packaging.
Discussion
Netac has the special distinction of being the first brand I’ve come across where the card was actually bigger than what was advertised. Note that it’s not this card — I received an 8GB Netac card (not the Pro) with my 3D printer. Upon closer inspection, however, I found that the card had only been partitioned to 8GB — and was, in fact, a 16GB card. I’ll admit that it did make me a little curious to see if any of Netac’s other cards would be the same way.
Performance measurements from these cards were disappointing — especially for a “PRO” card. All performance measurements were below average:
- Sequential read speeds were all more than one standard deviation below average. The worst of the three scores would put the card into the 8th percentile in this category, while the best would have only put it into the 22nd percentile.
- Sequential write speeds were all less than one standard deviation below average. The worst of the three scores would put this card into the 32nd percentile in this category, while the best would have only put it into the 36th percentile.
- Random read speeds for one of the three samples was more than one standard deviation below average, while the other two were less than one standard deviation below average. The worst of the three speeds would put this card into the 14th percentile in this category, while the best would put it into only the 32nd percentile.
- Random write speeds were all less than one standard deviation below average. The worst of the three scores would put this card into the 30th percentile in this category, while the best would have only put it into the 37th percentile.
These speeds were enough to qualify for the U1 and V10 markings, but both of the random I/O metrics fell short of what’s required for the A1 marking. I’ll throw in my standard “perhaps this card would have performed better if it had been tested under proper conditions” disclaimer. However, given the results that I got, I doubt that it could get its random write speeds up into the range needed to qualify for this marking.
On the endurance front:
Sample #1 did manage to pass the 2,000 read/write cycle mark without issues. Curiously, however, it randomly disconnected itself during round 2,110. When I pulled it from the reader and put it back in, it suddenly registered as a 2GB card instead of a 16GB card. After verifying this with the Realtek reader, I decided to declare this card “dead”.
Since this card was still responding to commands, and since I had dumped the CID, CSD, SSR, and SCR registers before starting any sort of testing on it, I decided to dump them again and compare the two. There were stark differences between the two: the SSR was now reading as all zeroes, and the other registers’ values had now changed almost completely:
Register Value Before Value After CID 6f0303434241445310aa000667017601
8903034e43617264101930291200a101
CSD 400e00325b59000076c67f800a404001
0026ff325f5a83b92db7ff9f96400001
SCR 02b5800300000000
0225000000000000
In the “after” values, the OEM ID and hardware revision ID had somehow managed to escape unchanged, but almost all other values didn’t: the manufacturer ID changed to
0x89
(which mmc-utils has listed as “Unknown”), the product ID had changed toNCard
(?????), the serial number was completely different, and the manufacture date had changed to January 2010. Normally I would just assume that these values were being stored in the card’s flash (although probably a different section of flash than the flash core) and that this portion of the flash had become corrupted — but the fact that the product ID changed toNCard
really struck me as odd. The values in the CSD register seem…sane-ish. So…did this card’s controller have some default values programmed into it, and for some reason it reverted to those values? Did it have an entire backup program that it reverted to using?? I might never know for sure.- Sample #2 has survived for 7,860 read/write cycles and has not yet experienced any errors.
- Sample #3 has survived for 7,787 read/write cycles.
Side note: Sample #3 did technically experience a couple errors; however, I’m almost positive that the errors were due to device mangling and thus not the card’s fault. Therefore, I’ve decided to discard those errors.
July 5, 2024 (current number of read/write cycles is updated automatically every hour)
OV 32GB
- Obtained from: AliExpress
- Price paid: $5.48
- Advertised capacity: 32GB
- Logical capacity: 31,719,424,000 bytes
- Physical capacity: 31,719,424,000 bytes
- Fake/skimpy flash: Skimpy (0.88% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.61%
- Speed class markings: Class 10, U1*, U3, V10*, V30, A1*, A2**
- CID data:
- Manufacturer ID:
0xad
- OEM ID:
0x4c53
(ASCII:LS
) - Product name:
0x5553443030
(ASCII:USD00
) - Product revision:
0x10
- Manufacturer ID:
* The U1, V10, and A1 marks only appear on the packaging — they do not appear on the card.
** The A2 mark only appears on the card — it does not appear on the packaging.
Discussion
This is another one I found on AliExpress after doing some more digging. I appreciated that they put at least a little bit of work in designing the artwork for both the packaging and the card, although the two designs seem to be completely different — almost as if two different people were working on the designs, and they