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 16GB and the Somnambulist 128GB 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:
- ATP Industrial 4GB
- 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 ImageMate Pro 128GB
(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 11/20/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.
November 20, 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 well over a year, has completed over 73,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 166 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 29 read/write cycles per day. Larger cards are moving even more slowly: for example, the three Hiksemi NEO 128GB samples have averaged between 4.7 and 7.7 read/write cycles per day. At these rates, it takes between 9 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,314, with a median value of 1,294 (n=162, min=0, max=20,876).
- In terms of percentiles:
- 99th percentile was 18,591 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,591 read/write cycles.)
- 95th percentile was 9,332 read/write cycles.
- 90th percentile was 6,332 read/write cycles.
- 75th percentile was 2,504 read/write cycles.
- 50th percentile was 1,375 read/write cycles.
- 25th percentile was 310 read/write cycles.
- 10th percentile was 11 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,295 read/write cycles, with a median value of 1,431 (n=32, min=0, max=20,876); for name-brand cards from AliExpress, the average was 1,456 read/write cycles, with a median value of 923 (n=39, 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,516 read/write cycles, with a median value of 1,407 (n=74, min=0, max=20,876); while the average for off-brand cards was 2,499 with a median value of 1,522 (n=69, 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,653 read/write cycles before first error, with a median value of just 439 (n=27, min=0, max=10,582); for authentic cards, the average was 2,578, with a median value of 1,521 (n=135, min=0, max=20,876).
- 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, min=246, max=320).
- 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 | 162 | 39 | 120 | 74 | 60 | 135 | 27 |
99pth | 18,591 | 20,448 | 13,391 | 20,053 | 14,629 | 19,104 | 10,258 |
95pth | 9,332 | 18,041 | 9,261 | 8,779 | 10,757 | 9,707 | 9,028 |
90pth | 6,332 | 5,252 | 5,652 | 5,345 | 6,973 | 6,258 | 6,685 |
75pth | 2,504 | 2,065 | 2,369 | 2,541 | 3,013 | 2,649 | 1,254 |
50pth | 1,375 | 1,453 | 909 | 1,407 | 1,699 | 1,521 | 439 |
25pth | 310 | 897 | 157 | 416 | 317 | 384 | 32 |
10pth | 11 | 162 | 5 | 120 | 11 | 37 | 2 |
5pth | 0 | 113 | 0 | 3 | 2 | 1 | 0 |
1pth | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
* Not including fake flash.
November 28, 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 something else entirely. 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 4,096, with a median value of 2,093 (n=77, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAliExpress=64, nAmazon=13).
- The data so far consists primarily of off-brand cards (nNameBrand=18, nOffBrand=41, nKnockoff=18).
- The data so far consists of mostly authentic flash (nAuthentic=51, nFake=26).
- Unsurprisingly, fake flash compared significantly worse than authentic flash.
- The average time to 0.1% failure for authentic flash was 5,229 read/write cycles, with a median value of 3,181 (n=51, min=0, max=20,876).
- The average time to 0.1% failure for fake flash was 1,873 read/write cycles, with a median value of 652 (n=26, min=0, max=10,761).
- 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.
November 28, 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 4,463 read/write cycles, with a median value of 2,188 read/write cycles (n=75, min=0, max=20,876).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=12, nAliExpress=63).
- The data so far consists of mostly off-brand cards (nNameBrand=18, nOffBrand=39, nKnockoff=18).
- The data so far consists mostly of authentic flash (nAuthentic=49, nFake=26).
- 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,749, with a median value of just 763.
- The average number of read/write cycles endured before reaching 1% failure for authentic flash was 5,372, with a median value of 4,035.
- 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 Amazon vs. AliExpress, the numbers are about even, with AliExpress cards having a slight lead over the Amazon cards.
- 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 75 cards represented here, about half of them (38) 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.
November 28, 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 4,837 read/write cycles, with a median value of 2,209 (n=71, min=0, max=22,535).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=12, nAliExpress=59).
- The data so far consists of mostly off-brand cards (nNameBrand=18, nOffBrand=37, nKnockoff=16).
- The data so far consists of mostly authentic flash (nAuthentic=47, nFake=24).
- 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 3,028, with a median value of 1,143.
- The average number of read/write cycles completed before reaching the 10% failure threshold for authentic flash was 5,761, with a median value of 3,181.
- 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 in favor of 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 71 cards represented here, 44 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.
November 28, 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 4,787 read/write cycles, with a median value of 2,209 (n=69, min=0, max=24,252).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=12, nAliExpress=57).
- The data so far consists mostly of off-brand cards (nNameBrand=17, nOffBrand=36, nKnockoff=16).
- The data so far consists mostly of authentic flash (nAuthentic=46, nFake=23).
- 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,474, with a median value of 952.
- The average number of read/write cycles completed before reaching the 25% failure threshold for authentic flash was 5,944, with a median value of 3,698.
- 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 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 69 cards represented here, 49 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.
November 28, 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 4,870 read/write cycles, with a median value of 2,533 (n=69, min=0, max=26,041).
- The data so far consists primarily of cards sourced from AliExpress (nAmazon=12, nAliExpress=57).
- The data so far consists mostly of off-brand cards (nNameBrand=17, nOffBrand=36, nKnockoff=16).
- The data so far consists mostly of authentic flash (nAuthentic=46, nFake=23).
- Once again, fake flash fared significantly worse than authentic flash.
- The average number of read/write cycles to complete failure for authentic flash was 6,036, with a median value of 3,826.
- The average number of read/write cycles to complete failure for fake flash was 2,538, with a median value of 1,283.
- 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 AliExpress.
- Between name-brand cards and off-brand 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 completely failing.
November 28, 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: Delkin Devices HYPERSPEED The internal data says that this card should be identical to the PNY Premier-X, but it suffers from lower sequential read speeds compared to the PNY version. Regardless, it still performed well in all other metrics. This makes it well suited for random I/O-intensive applications, such in a single-board computer like the Raspberry Pi.Available from: Amazon |
#5: 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 |
#6: 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 |
#7: 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 |
#8: 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 |
#9: 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 |
#10: 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 |
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.
November 17, 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 survived 2,476 read/write cycles so far and has not yet experienced any errors. (If you’ve been paying close attention to this one, you might remember that I said it was going at a snail’s pace because it was plugged into the same reader as sample #2, and that card was giving non-stop I/O errors, causing it to need to be constantly reset. However, another reader freed up since then, so I moved it over to that reader, which has allowed it to resume testing at normal speeds.)
- Sample #2’s first error was a series of bit flips, affecting two sectors, during round 1,559. It has survived 1,662 read/write cycles in total so far. As I mentioned above, it’s currently experiencing a high number of I/O errors on read operations. I’m hoping that my program will eventually determine which parts of the card are bad and avoid those in future rounds; however, it may take some time for this to happen.
- 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.
November 28, 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 5,821 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 3,148 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 3,162 read/write cycles in total so far.
- Sample #4 has survived 2,876 read/write cycles so far and has not yet experienced any errors.
November 10, 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 survived another 1,900 or so read/write cycles before it stopped responding to commands. Interestingly, it — unlike the other two samples below — never made it past the 0.1% error threshold before failing.
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.
December 16, 2024
ATP Industrial 4GB
- Obtained from: AliExpress
- Price paid: $6.08
- Advertised capacity: 4GB
- Logical capacity: 4,125,097,984 bytes
- Physical capacity: 4,125,097,984 bytes
- Fake/skimpy flash: No
- Protected area: 33,554,432 bytes
- Adjusted skimp: -3.97%
- Speed class markings: None
- CID data:
- Manufacturer ID:
0x09
- OEM ID:
0x4150
(ASCII:AP
) - Product name:
0x4146205544
(ASCII:AF UD
) - Product revision:
0x10
- Manufacturer ID:
Discussion
I don’t remember exactly how I came across ATP as a brand name — I think it may have been while searching for microSD cards on Digikey. Unfortunately, even the cheapest of ATP’s cards would have been out of my budget. I eventually landed on some being sold on AliExpress. Funnily enough, I had to order them twice: the first time, the package made it partway into the US before the the USPS decided that it didn’t have enough postage and that it wasn’t going to be delivered. (I didn’t even get a “postage due” notice…) Fortunately, AliExpress refunded it and I was able to reorder it. (And when I went to reorder it, I discovered that it was cheaper to order a 5-pack instead of three individual cards.)
These cards were packaged in a simple plastic case. As you can see from the picture, this wasn’t even a microSD card case — it was just a simple plastic box, and the cards were allowed to float around inside. Although it’s not unusual for such cards to be sold without retail packaging — they’re being sold to industrial customers, so the packaging would just be unnecessary waste — the fact that they weren’t packaged in a case suitable for microSD cards seems just…lazy.
I’m not 100% convinced that these are authentic, but at the same time, I’m not 100% convinced that they’re fake. (And in this context, I’m referring to the authenticity of the cards themselves — whether they are genuine ATP products or knockoffs.) So far it seems that their performance is pretty atrocious. But then again, knockoff manufacturers don’t usually bother trying to make the CID register look authentic. If it is authentic, it’s old — the CID data on the two cards that I’ve tested so far indicate that they were manufactured in 2011 — which would explain why I was able to get it for so cheap. It could be that these are used cards that are being resold.
I reached out to ATP to ask if they could authenticate the card, but as of this writing, I haven’t heard back from them.
On the endurance front:
- Sample #1’s first error was a string of two write failures — one 512 sectors long, the other 1,536 sectors long — during round 3,624. It has survived 7,322 read/write cycles in total so far.
- Sample #2 has survived 4,595 read/write cycles so far and has not yet experienced any errors.
- Samples #3-#5 are still in the package, waiting to be tested.
December 4, 2024 (current number of read/write cycles updates 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, even compared to the industrial-rated cards that I've tested. 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.
November 4, 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 0.1% failure threshold | 0 | 8 | 0 | 3 |
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.
November 4, 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.
November 4, 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 11,493 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 12,905 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.
November 4, 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.
November 4, 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 (inaccessible)
- 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. 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 the results were pretty consistent across all three samples — so it’s not like the results were a fluke.
All three samples are currently going through endurance testing:
- Sample #1 has survived 2,368 read/write cycles so far and has not yet experienced any errors.
- Sample #2 has not yet reached the 2,000 read/write cycle mark. It’s too early to make any estimates on when it will get there.
- Sample #3 has not yet reached the 2,000 read/write cycle mark. It’s too early to make any estimates on when it will get there.
December 4, 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 two 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.
On the endurance testing front:
- Sample #2’s first error was a four-sector wide address decoding error during round 382. It survived another 3,700 or so read/write cycles until it decided to quit suddenly — one day the USB hub (where this card’s card reader was plugged in) failed and needed to be reset; after the reset, this card refused to respond to commands.
- Sample #3’s first error was a series of bit flip errors, affecting 74 sectors, during round 1,786. It has survived 4,051 read/write cycles in total so far.
- Sample #4’s first error was a series of bit flips, affecting 10 sectors, during round 2,096. It continued to do just fine up until the end of round 4,545 — at that point, I shut down all of my testing rigs so that I could do some electrical work on my house. When I turned the power back on, this card would not respond to commands.
- Sample #5’s first error was a series of bit flips, affecting two contiguous sectors, during round 1,843. It has survived 3,265 read/write cycles in total so far.
- Sample #6’s first error was a series of bit flips, affecting four contiguous sectors, during round 1,837. It has survived 1,904 read/write cycles in total so far.
December 20, 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 79,070 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 444 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 535.5 TiB.
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 continued to do well until round 19,852, when a large number of sectors just started to return all
ff
‘s. It crossed the 50% failure threshold during round 19,886.
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.
November 4, 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 0.1% failure threshold | 9,449 | 5,165 | Not yet determined | 7,307 |
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 6,880 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 6,732 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.
November 4, 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,626 read/write cycles in total so far.
- Sample #2 experienced a two-sector wide data verification error during round 110; it has survived 2,433 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,659 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.
November 4, 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 2,386 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 2,388 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 2,914 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.
November 4, 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,891 read/write cycles in total so far.
- Sample #2’s first error was a single bit flip, in a single sector, during round 1,295. It has survived 1,847 read/write cycles in total so far.
- Sample #3’s first error was a single bit flip, in a single sector (noticing a pattern here?), during round 680. It has survived 1,847 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Integral Security 32GB
- Ordered from: Amazon UK
- Price paid: £10.52 (about $13.82)
- Advertised capacity: 32GB
- Logical capacity: 31,058,821,120 bytes
- Physical capacity: 31,058,821,120 bytes
- Fake/skimpy flash: Skimpy (2.94% skimp)
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10, U1*, V1
- CID data:
- Manufacturer ID:
0x27
** - OEM ID:
0x5048
(ASCII:PH
)** - Product name:
0x5344333247
(ASCII:SD32G
) - Product revision:
0x60
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to belong to Phison.
** The U1 marking appears on the package, but does not appear on the card itself.
Discussion
This particular brand is one that I found thanks to an online survey I found, where someone was asking which microSD card had the highest endurance. One of Integral Memory’s cards was listed as one of the options. Neither Amazon nor AliExpress had them available for sale — but Amazon UK did, and for a price that was within my parameters.
Looking at the CID data reveals that this is likely produced for Integral by Phison. So far, Phison’s cards have performed decently well, so I’m expecting good things out of this card.
All performance metrics were above average, with random read speeds being more than one standard deviation above average. In fact, this card did well enough on random I/O performance that it would have qualified for the A1 marking. Alas, Integral chose not to put this label on the card. Sequential write speeds were only just slightly above average — in fact, as far as sequential write speeds go, this card is the worst performing Phison card that I’ve tested so far. However, these results are only based off the results from a single card — so we’ll have to wait until I’m able to test the other two to see how they do.
As far as endurance testing goes:
- Sample #1 was doing quite well for the first 4,331 read/write cycles; but during round 4,332, it experienced a…strange sort of data verification failure: the same 16 sectors’ worth of data was repeated over and over again — 526 times, to be exact. I’m not sure where the data came from either, as it failed CRC checks (meaning that it wasn’t the data my program wrote to the card). However, during round 4,333, it decided to stop responding to commands altogether.
- Samples #2 and #3 are still in the package waiting to be tested.
December 16, 2024
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’s first error was a single bit flip, in a single sector, during round 3,002. It has survived 4,273 read/write cycles in total so far.
- Sample #2’s first error was a single bit flip, in a single sector, during round 1,746. It has survived 4,262 read/write cycles in total so far.
- Sample #3 has survived 2,641 read/write cycles so far and has not yet experienced any errors.
November 4, 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 0.1% failure threshold | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
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 12,532 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,648 read/write cycles in total so far.
- Sample #3 has survived 9,922 read/write cycles and has not yet experienced any errors.
- Sample #4 experienced a address decoding error during round 2,729. It has survived 13,867 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 11,728 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 9,440 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.
November 4, 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 22,051 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 36,100 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 36,090 read/write cycles in total so far.
November 4, 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 | 1,591 | 923 | 1,694 |
Number of read/write cycles to 0.1% failure threshold | 2,568 | Not yet determined | 2,999 | Not yet determined | 2,784 |
Number of read/write cycles to complete failure | 2,568 | Not yet determined | 2,999 | Not yet determined | 2,784 |
Total days to complete failure | 66 | Not yet determined | 167 | Not yet determined | 117 |
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.
On the endurance testing front:
- 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.
- Sample #2 has survived 5,204 read/write cycles so far and has not yet experienced any errors.
- Sample #3’s first error was a write failure, that affected 32 contiguous sectors, during round 1,592. Then, sometime during round 3,000, for some unknown reason, it decided to just stop responding to commands.
- Sample #4’s first error was a single bit flip, in a single sector, during round 924. It has survived 3,826 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.
November 13, 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,993 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 7,264 read/write cycles so far.
- Sample #3 has survived 6,458 read/write cycles so far and has not yet experienced any errors.
November 4, 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 7,896 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 7,484 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 7,786 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.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Kodak Ultra Performance 32GB (Yellow Version)
- 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 0.1% failure threshold | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
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 7,709 read/write cycles so far.
- Sample #2 has survived 3,858 read/write cycles so far and has not yet experienced any errors.
- Sample #3 has survived 3,857 read/write cycles so far and has not yet experienced any errors.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Kodak Ultra Performance 64GB (Black Version)
- 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 0.1% failure threshold | 4,215 | Not yet determined | Not yet determined | 4,215 |
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 3,332 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 3,334 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.
November 4, 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.
My recommendation? They’re fake flash, they scored below average in just about every metric, and not a single one of them made it to the 2,000 read/write cycle mark. They’re trash — don’t buy them.
November 4, 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 since late August.
Samples #2 and #3 are still in the package waiting to be tested.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
"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, this model endured far better than its 128GB sibling: Sample #1 completed 5,601 read/write cycles before showing any errors; sample #3 completed 8,311 read/write cycles before showing any errors; and sample #2 has yet to show any errors.
Curiously, with sample #1, 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.
Sample #1 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 seeming to resemble the data written at all — which were then separated by a number of read/write cycles where no data mismatch errors occurred. The number of intervening rounds 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 technique (probably dynamic wear leveling), it wasn’t detecting the bad sectors, and it was simply recycling those portions of the card 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 this round — as well as over the next five 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 had shot up to 43.089%. Then, sometime during round 11,634, the card stopped responding to commands altogether.
Since this card made it so close to the 50% failure threshold, I’ll go ahead and post a chart showing its progression:
- Sample #2’s first error was a series of bit flips, affecting two contiguous sectors, during round 10,583. It has survived 12,235 read/write cycles in total so far.
Sample #3’s first error was a series of bit flips, affecting two contiguous sectors, during round 8,311. It managed to survive a total of 11,757 read/write cycles before it crossed the 50% failure threshold. Here’s the graph of this card’s progression:
November 24, 2024 (current number of read/write cycles is updated automatically every hour)
Lenovo thinkplus Pro 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 936 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 970 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 985 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.
November 10, 2024 (current number of read/write cycles updates automatically every hour)
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 10,720 read/write cycles so far.
- Sample #2’s first error was an address decoding error during round 268; it has survived 5,923 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 8,062 read/write cycles so far.
November 4, 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 5,127 read/write cycles so far.
- Sample #2 has survived 6,062 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,969 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.
November 4, 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 20,379 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 read/write cycles 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).
November 4, 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:
- Sample #1’s first error was a single bit flip, in a single sector, during round 2,258. It has survived 3,182 read/write cycles in total so far.
- Sample #2 has survived 3,182 read/write cycles and has not yet experienced any errors.
- Sample #3’s first error was a series of bit flip errors affecting 1,450 sectors during round 4. It has survived 1,684 read/write cycles in total so far.
November 4, 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’s first error was an address decoding error, that affected four contiguous sectors, during round 9,258. It has survived for 12,685 read/write cycles in total so far.
Sample #3’s first error was a four-sector wide address decoding error during round 4,122. It continued to chug along — with a few other minor errors — until round 8,079, when about 3/8 of the total sectors on the card just started reading back as all
ff
‘s. (Strangely, these sectors all tested just fine during the next round of testing.) During the next few hundred rounds, more large numbers of sectors (usually a few hundred thousand at a time) would pop up occasionally. This pushed it over the 50% failure threshold during round 8,543.Side note: Sample #3 did technically experience a couple errors earlier on; 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.
Here’s the graph of what this card’s progression looked like:
November 10, 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 weren’t coordinating with each other. It appears that this particular manufacturer has their own line of memory products — including not only microSD cards, but also USB flash drives, SSDs (both internal and external), and RAM.
The package and card bear a strange combination of conflicting speed class marks, which would support my “the card and the packaging were designed by two different people” theory. Despite the disagreement, none of the three samples performed well enough to meet the threshold for the U3, V30, A1, and A2 marks. Perhaps they would have performed well enough to qualify for the U3 and V30 marks had they been tested under the right conditions; but given how poorly they performed on the random I/O tests, I doubt that it would have performed well enough for either the A1 or A2 marks even under the right conditions.
On the endurance front, it’s looking like a mixed bag. As of this writing:
- Sample #1’s first error was an I/O error during round 405. It has completed 11,869 read/write cycles so far.
- Sample #2 managed to get past the 2,000 read/write cycle mark without issues; its first error was an address decoding error during round 2,203. It has completed 10,632 read/write cycles total so far.
- Sample #3’s first error was a four-sector wide address decoding error during round 2,538. It has survived 8,606 read/write cycles so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
PNY Elite-X 64GB
- Obtained from: Amazon
- Price paid: $6.31
- 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
- Adjusted skimp: 2.56%
- Speed class markings: Class 10, 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
It wasn’t until pretty late into this project that I realized that PNY hadn’t been represented in my survey thus far. I hadn’t managed to find any PNY cards on AliExpress — at least, not any PNY-branded cards — so I had to look at what Amazon had. I chose two models: this, and the Premier-X 128GB. As you may have guessed from the pictures, this card was offered in a three-pack — so the price you see above is divided evenly between the three cards.
Performance-wise, this card scored slightly above average in all performance metrics, with the exception of random write scores — where all three samples scored more than one standard deviation above average, almost nearly two standard deviations above average. The worst of the three random write scores would put it in the 92nd percentile. Not bad!
These cards bear the Class 10, U3, V30, and A1 performance marks. All three samples performed well enough to qualify for all of these marks.
All three samples are currently undergoing endurance testing:
- Samples #1’s first error was a two-sector wide address decoding error during round 948. It has survived 3,551 read/write cycles in total so far.
- Sample #2’s first error was a two-sector wide address decoding error during round 875. It has survived 3,529 read/write cycles in total so far.
- Sample #3’s first error was a four sector wide address decoding error during round 2,461. It has survived 3,706 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
PNY Premier-X 128GB
- Obtained from: Amazon
- Price paid: $12.99
- Advertised capacity: 128GB
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: Class 10*, U3, V30, A1
- CID data:
- Manufacturer ID:
0x27
** - OEM ID:
0x5048
(ASCII:PH
) - Product name:
0x5344313238
(ASCII:SD128
) - Product revision:
0x60
- Manufacturer ID:
* The Class 10 mark 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 Phison.
Discussion
This card, along with the PNY Elite-X 64GB, are the first PNY-branded cards that I’ve purchased as part of this project — which, honestly, seems like an oversight on my part. (How could I forget about PNY?)
Performance-wise, this card performed pretty well — it looks like it doesn’t support the enhanced speeds that SanDisk’s cards do — which meant that sequential read speeds were only slightly above average — but it did exceptionally well with sequential write speeds, putting them in the 95th percentile. Random read and write speeds were all more than one standard deviation above average, with two of the three samples getting random write speeds that were more than two standard deviations above average. The worst of the three random write scores would put it into the 87th percentile in this category, while the worst of the random read scores would put it into the 85th percentile. In fact, the worst performance measurement between all three samples would put this card into the 84th percentile.
This card carries the U3, V30, and A1 markings. Additionally, the package carries the Class 10 marking. All three samples performed well enough to qualify for all of these markings. (Well done, PNY!)
All three samples are currently undergoing endurance testing:
- Sample #1’s first error was…well, I don’t know what to make of it. It was a data mismatch error of some sort that only affected one sector during round 589 — but it only affected the last four bytes of the sector (where I store the CRC for that sector). And on top of that, the CRC check passed — which tells me that either something was wrong with the CRC check, or the data I reconstructed was wrong. I’m not sure what to make of it. At any rate, it has survived 2,000 read/write cycles in total so far.
- Sample #2’s first error was a single bit flip, in a single sector, during round 1,400. It has survived 1,994 read/write cycles in total so far.
- Sample #3’s first error was a single bit flip, in a single sector, during round 387. It has survived 1,893 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
QEEDNS 8GB
- Advertised capacity: 8GB
- Logical capacity: 8,053,063,680 bytes
- Physical capacity: 8,053,063,680 bytes
- Fake/skimpy flash: No
- Protected area: 0 bytes
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x534d492020
(ASCII:SMI
) - Product revision:
0x00
- Manufacturer ID:
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $2.57 | $2.48 | $2.48 | $2.51 |
Manufacture date | Nov 2015 | Sep 2023 | Sep 2023 | N/A |
Serial number | 0x0x000007ff | 0x00000000 | 0x00000000 | N/A |
Sequential read speed (MB/sec) | 17.94 | 17.68 | 17.87 | 17.83 |
Sequential write speed (MB/sec) | 14.12 | 10.83 | 10.79 | 11.91 |
Random read speed (IOPS/sec) | 1,170.16 | 1,009.59 | 1,033.61 | 1,071.12 |
Random write speed (IOPS/sec) | 35.89 | 32.85 | 26.07 | 31.60 |
Read/write cycles to first error | 6,111 | 4,576 | 0 | 3,562 |
Read/write cycles to 0.1% failure threshold | 6,111 | 4,577 | 4,596 | 5,095 |
Read/write cycles to complete failure | 6,111 | 4,577 | 4,596 | 5,095 |
Total days to complete failure | 79 | 109 | 108 | 99 |
Card reader used | SanDisk MobileMate | 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
QEEDNS (I’m just assuming it’s spelled in all upper-case, because that’s how it’s printed on all of their cards) is another brand that popped up with some regularity when I was browsing AliExpress. This card arrived in a generic red packaging that seems to have been shared with a few other brands, such as Auotkn, Microdrive, the knockoff Lenovo cards, SanDian, and the knockoff Sony cards. This packaging did not have any brand name, manufacturer information, the size of the card, or class markings on it — it was about as generic a package as you could get for an SD card. I think I only bought one of these because this was another case where I wanted to see if I could find fake and genuine cards from the same manufacturer — however, I purchased two more later after I made the decision to try to test three of each model.
This card had its manufacturer ID and OEM ID set to all zeroes, a trait shared by several other off-brand/knockoff/fake cards. I suspect that this was done intentionally because whoever manufactured these cards likely doesn’t want their name associated with it. Bunnie (from Bunnie Studios) used the term “ghost shift” to describe runs of SD cards that are generally run off the books and using marginal material that would normally be disposed of — and I suspect that these cards are likely a result of these ghost shifts.
Performance-wise, this card performed pretty poorly. Sequential read speeds were more than one standard deviation below average, with the worst of the three scores putting it into only the 9th percentile in this category. Random write scores were also more than one standard deviation below average, with the worst of the three scores putting it into only the 14th percentile. In fact, the highest of any of the performance measurements was sample #1’s random read speeds — which was only enough to put it into the 25th percentile. And yet, somehow it did well enough to qualify for the Class 10 and U1 marks that it carries.
Sample #1 actually did fairly well on its endurance tests — right up until it failed. One day, I decided to mount my USB hubs on the wall of my server closet, and a few days later, I decided to mount the AC adapters for these hubs by hammering cable tacks into the wall where the cords were going into it. I must have jarred something when I was doing this, because all of the card readers on that host suddenly disconnected from the machine. I had to reset the entire USB controller to get them working again. I managed to get all of the other cards working again, but this card refused to come back to life — it simply refused to respond to commands. I made several attempts (including with my trusty Realtek reader), but to no avail — at which point I decided to simply declare the card dead.
Samples #2 and #3 were a little bit odd.
Sample #2 was doing just fine until round 4,577, when it started experiencing a large number of I/O errors. I added some code recently to detect and avoid sectors that experienced non-stop I/O errors, so I decided to just let it run and see if it would eventually get past the affected area. It did — but once it did, it started experiencing a large number of bit flip errors. Eventually even that gave way to something even stranger: every sector reading back as the same 8 bytes — 88 16 03 27 91 26 89 26
— repeated over and over again:
[Fri Aug 30 00:54:31 2024] Expected data was:
[Fri Aug 30 00:54:31 2024] 0000000149fffe00: 9f 04 14 af 9d ad 08 fa 99 71 9e ec 69 cb bb 48
[Fri Aug 30 00:54:31 2024] 0000000149fffe10: 9b 20 2f f3 d3 f9 80 80 3f 70 07 76 0e 76 b3 6b
[Fri Aug 30 00:54:31 2024] 0000000149fffe20: fa 48 4a d2 18 ec 6f c8 d7 0f 4e e6 be 46 ff 81
[Fri Aug 30 00:54:31 2024] 0000000149fffe30: 08 bb f4 de 81 af 99 f1 06 29 96 a9 79 68 d6 fe
[Fri Aug 30 00:54:31 2024] 0000000149fffe40: ad cb e8 88 e0 ad e4 c0 5a 29 aa c4 89 f2 3e b5
[Fri Aug 30 00:54:31 2024] 0000000149fffe50: 9d 69 98 9e 46 5a c3 e8 05 c5 41 a6 31 df c3 83
[Fri Aug 30 00:54:31 2024] 0000000149fffe60: af ec c0 b9 47 18 e5 b9 3f a5 1e a6 0f 13 0b 8d
[Fri Aug 30 00:54:31 2024] 0000000149fffe70: b0 9e 07 85 6f 78 3f bb 01 10 22 88 24 72 3f a2
[Fri Aug 30 00:54:31 2024] 0000000149fffe80: fb 60 cd 96 6c 46 08 e8 6f 24 d0 fe 50 30 07 d0
[Fri Aug 30 00:54:31 2024] 0000000149fffe90: 60 78 15 f5 8a a9 5f b0 cc 5b c7 d3 ea e3 b8 ac
[Fri Aug 30 00:54:31 2024] 0000000149fffea0: a1 1c af c3 a8 a4 cf 9b 0b 28 a7 8d 7d bd 4f f9
[Fri Aug 30 00:54:31 2024] 0000000149fffeb0: 60 9f 76 ae 9b f8 fb a7 9d f9 b8 a6 14 f0 dc a9
[Fri Aug 30 00:54:31 2024] 0000000149fffec0: ee d1 3e 84 de 5a df 9e f1 54 c8 ba dd 70 71 e9
[Fri Aug 30 00:54:31 2024] 0000000149fffed0: ba e0 8f ff cd b6 78 b3 09 8d aa b2 e3 68 a7 f8
[Fri Aug 30 00:54:31 2024] 0000000149fffee0: 0f a2 2a f1 07 41 f8 e6 f1 75 4e e8 cc 83 53 94
[Fri Aug 30 00:54:31 2024] 0000000149fffef0: 09 cb 7d f6 ff b8 8c af 24 b1 d2 a1 cb 30 9e fa
[Fri Aug 30 00:54:31 2024] 0000000149ffff00: 2e 40 30 a6 84 41 fa 86 65 b1 f4 b9 af c7 e7 89
[Fri Aug 30 00:54:31 2024] 0000000149ffff10: 4e 58 4f 97 a0 61 c9 a7 80 b6 1d e3 7a ff 67 b5
[Fri Aug 30 00:54:31 2024] 0000000149ffff20: 92 eb d7 fd 6a fb 25 e4 28 42 25 e6 30 fd 19 c5
[Fri Aug 30 00:54:31 2024] 0000000149ffff30: b2 ac b3 b6 b8 d5 49 e0 31 3e 20 df de 09 09 e8
[Fri Aug 30 00:54:31 2024] 0000000149ffff40: be b7 ed a8 18 e1 97 ed a2 d3 d6 a2 3f 3d 6f c1
[Fri Aug 30 00:54:31 2024] 0000000149ffff50: 85 97 32 aa 8a 5c 74 d0 bb 3b 38 d4 6a 28 f9 8d
[Fri Aug 30 00:54:31 2024] 0000000149ffff60: b2 40 de c7 f1 e5 fc ed 00 f9 07 fb b1 97 0f 80
[Fri Aug 30 00:54:31 2024] 0000000149ffff70: 20 10 4f bb 22 20 71 c3 46 92 b0 e5 42 f3 7d fc
[Fri Aug 30 00:54:31 2024] 0000000149ffff80: ae 39 86 e4 1e 5e 56 e3 6e 8e 5d b3 ce 06 73 a8
[Fri Aug 30 00:54:31 2024] 0000000149ffff90: 58 b0 d2 d8 24 0c 9a ac 0e f0 52 d9 af 0c 02 9d
[Fri Aug 30 00:54:31 2024] 0000000149ffffa0: 57 b1 d1 b8 62 d9 78 c6 e0 96 c8 bf 40 36 3f ee
[Fri Aug 30 00:54:31 2024] 0000000149ffffb0: db 2e 3b 96 79 28 f4 bc 8d 18 d1 e6 7b ea 0f eb
[Fri Aug 30 00:54:31 2024] 0000000149ffffc0: 5a 45 ef 89 4b 9a b7 c4 28 0b 29 ae e3 eb b8 ad
[Fri Aug 30 00:54:31 2024] 0000000149ffffd0: b0 a2 31 e1 ba 2f dc 93 9d 98 83 8c ac 3a ae fd
[Fri Aug 30 00:54:31 2024] 0000000149ffffe0: b4 7b a6 e4 a5 f1 f4 cc 72 75 48 e1 7b 40 c6 d7
[Fri Aug 30 00:54:31 2024] 0000000149fffff0: 7b f9 52 87 9f aa 25 a9 6a db c3 a3 5c 81 12 0b
[Fri Aug 30 00:54:31 2024]
[Fri Aug 30 00:54:31 2024] Actual data was:
[Fri Aug 30 00:54:31 2024] 0000000149fffe00: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe10: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe20: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe30: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe40: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe50: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe60: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe70: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe80: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffe90: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffea0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffeb0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffec0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffed0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffee0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffef0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff00: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff10: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff20: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff30: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff40: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff50: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff60: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff70: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff80: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffff90: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffffa0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffffb0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffffc0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffffd0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149ffffe0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
[Fri Aug 30 00:54:31 2024] 0000000149fffff0: 88 16 03 27 91 26 89 26 88 16 03 27 91 26 89 26
This happened early enough in the read-back portion of the round that it affected more than 50% of the sectors on the device — which caused the endurance test to end.
Sample #3 was also doing well — minus a few minor issues early on — but it started experiencing I/O errors around the same time as sample #2. Maybe this was because they were both plugged into the same reader — I don’t know. I took the same approach: just let the code do what it does and work past the I/O errors. Once it finally did, it came to light that nearly every sector experienced a write failure (where the data that we read back was actually written during a previous round of testing). Since this affected more than 50% of the sectors on the device, the endurance test ended at that point.
My conclusion: don’t buy these. Yes, they’re cheap; and even if it turns out that the results of endurance testing show them to be reliable, their poor performance just doesn’t justify it. With a little bit of searching, you can find better options. In fact, at the time I’m writing this, AliExpress has the HP microSDXC mx330 64GB — a PNY-made card that scored much better on performance metrics — available in their bundle sale for just a penny more than what I paid.
November 4, 2024
QEEDNS 512GB
- Advertised capacity: 512GB
- Logical capacity: 536,871,960,576 bytes
- Fake/skimpy flash: Fake flash
- Speed class markings: Class 10, U3
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | AliExpress | AliExpress | AliExpress | N/A |
Price paid | $12.17 | $14.01 | $14.01 | $13.40 |
Physical capacity | 31,434,108,416 bytes | 31,058,935,296 bytes | 31,058,935,296 bytes | 31,183,993,003 bytes |
Protected area | 0 bytes | 134,217,728 bytes (inaccessible) | 134,217,728 bytes (inaccessible) | N/A |
Manufacturer ID | 0x00 | 0x56 | 0x56 | N/A |
OEM ID | 0x0000 | 0x5344 (ASCII: SD ) | 0x5344 (ASCII: SD ) | N/A |
Product name | 0x4150505344 (ASCII: APPSD ) | 0x4150505344 (ASCII: APPSD ) | 0x4150505344 (ASCII: APPSD ) | N/A |
Product revision | 0x00 | 0x00 | 0x00 | N/A |
Manufacture date | Sep 2021 | Jul 2016 | Jul 2016 | N/A |
Serial number | 0x12800000 | 0x0000088b | 0x0000074b | N/A |
Sequential read speed (MB/sec) | 12.48 | 41.90 | 41.83 | 32.07 |
Sequential write speed (MB/sec) | 9.55 | 24.35 | 24.36 | 19.42 |
Random read speed (IOPS/sec) | 472.40 | 476.32 | 468.19 | 472.30 |
Random write speed (IOPS/sec) | 3.65 | 311.76 | 310.11 | 208.51 |
Read/write cycles to first error | 447 | 652 | 652 | 584 |
Read/write cycles to 0.1% failure threshold | 1,563 | 652 | 652 | 956 |
Read/write cycles to complete failure | 1,687 | 652 | 652 | 996 |
Total days to complete failure | 101 | 31 | 31 | 54 |
Card reader used | Lexar LRWM05U-7000 | 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
This is another card that I bought because I wanted to see if I could find genuine and fake flash in the same brand. And, it turns out that the answer is “Yes. Yes you can.”
Samples #2 and #3 were obtained separately from sample #1, and there appear to be some differences between them. For example, sample #1 had its manufacturer ID and OEM ID set to all zeroes — which, to me, screams of an attempt by the manufacturer to hide their true identity — while samples #2 and #3 had their manufacturer ID set to 0x56
and their OEM ID set to SD
. (No idea who manufacturer ID 0x56
is assigned to.)
There was also a marked difference in performance between the two sets: sample #1 performed more than one standard deviation below average in all performance metrics, with its scores putting it somewhere between the 3rd and 10th percentiles. Samples #2 and #3 fared better, but still scored below average — their scores put them somewhere between the 6th and 46th percentiles. Sample #1 just barely missed the 10MB/sec sequential write speeds that would have been needed to qualify for the Class 10 marking. Samples #2 and #3, however, easily met that threshold. None of the three met the 30MB/sec sequential write speeds that would have been needed to qualify for the U3 mark.
Sample #1 started having issues during round 448; however, its issues started ramping up around round 1,534. It hobbled along for quite a while afterwards — every so often (usually a few times a day towards the end), it would disconnect itself from the reader, and I would have to manually pull it and re-insert it into the reader to get it working again. It finally bit the dust during round 1,686 — it disconnected itself from the reader, and re-inserting it would no longer solve the problem.
Here’s what this sample’s progression looked like:
Why did the number of bad sectors drop after round 1,647? Because it was experiencing enough errors to the point where my program could no longer automatically detect the device after I plugged it back in, so I had to restart the test from scratch. Afterwards, I added an option to the program to force it to resume from a given device.
Samples #2 and #3, curiously, both failed just two hours apart from each other, and at the same number of read/write cycles (although this part is probably more due to the fact that I started them testing at about the same time). They both simply stopped responding to commands. They had not experienced any errors prior to this. However, when neither one would respond to commands when plugged into my Realtek reader, I decided to declare them dead.
November 4, 2024
QWQ Extreme Pro 16GB
- Obtained from: AliExpress
- Price paid: $2.99
- Advertised capacity: 16GB
- Protected area: 0 bytes
- Speed class markings: Class 10, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product revision:
0x00
- Manufacturer ID:
Discussion
In early 2024, AliExpress started running sales where items — seemingly from a single seller — were priced at either $1.99, $2.99, or $3.99, and you were allowed to purchase any combination of 10 items…I think per day? This one caught my attention for a couple of reasons: first, the bright orange color; and second, the fact that they offered it in a 618GB capacity — it’s rather odd for an SD card manufacturer to be offering a card in a size that isn’t a power of 2. However, given that the prices on all of the sizes were practically identical, the 618GB card is almost certainly fake, and hence I didn’t buy any of them (yet).
This particular brand also has two different card designs: one whose cards had a primarily orange and white design, and one whose cards had a primarily blue and black design. When I ordered these, I must have thought that there was a significant difference between the two — and if memory serves, I thought that one of them had the “Extreme Pro” label on it, and the other one didn’t — but after receiving them and looking at them more closely, I can’t see a difference between them. They both appear to have the “Extreme Pro” label — and thus, I’m going to lump them both under this section.
Plugging them in, however, revealed a few differences:
- The orange/white cards are fake — two of them were 8GB in size, while one was only 4GB in size. The blue/black cards, on the other hand, were genuine (if slightly skimpy).
- The orange/white cards have a different product name than the blue/black cards.
- The orange/white cards have unique serial numbers — whereas the blue/black cards all have the same serial number.
I’m guessing that all of this means that the seller sourced these cards from more than one manufacturer.
I was surprised that the first three samples turned out to be fake — usually smaller capacity cards like this are genuine. But, I suppose there are sellers who will skimp on just about anything to make a buck.
The performance on them so far has been…terrible. All performance metrics were below average, with most measurements being more than one standard deviation below average. In fact, its best single measurement — the random read score on sample #4 — was only enough to put it into the 37th percentile in that category.
This card bears the Class 10 and A1 marks; and while performance on 5 out of the 6 samples was good enough to qualify for the Class 10 mark, it missed the mark on both random read and random write speeds that would be needed for the A1 mark. And while I’ll throw in my standard disclaimer — that perhaps this card would have done better had it been tested under the proper conditions — I highly doubt it, especially with random write speeds as terrible as they were.
On the endurance front, 5 of the 6 samples are still undergoing endurance testing:
Sample #1 only managed to go for 18 read/write cycles before it experienced its first error. It managed to go for quite some time — with the number of errors continually increasing the entire time — but eventually it got to the point where any attempt to write to it would result in I/O errors. I made several attempts to get it to continue — switching it to different card readers, and even adding code to my program to avoid sectors that have continually exhibiting I/O errors — but eventually I had enough and just declared it “dead”. By the time it reached that point, about 14.66% of its sectors had already been marked “bad” — so it wasn’t that far off (relatively speaking) from hitting the 50% failure threshold on its own. Here’s what this sample’s progression looked like:
Sample #2 only managed to go for 4 read/write cycles before it encountered its first error. It continued to experience errors every few rounds — affecting about 1,024 sectors at a time — until round 763, when suddenly over half of the sectors started reading back as all
0xff
‘s. Here’s what this sample’s progression looked like:
- Sample #3’s first error was a data verification failure affecting 1,316 sectors during round 9,337. (I don’t want to call these bit flip errors, because the data doesn’t resemble the original data at all.) The odd part is that the sectors affected were non-contiguous — in fact, almost all of them occurred exactly 2,048 sectors after the previous one. (This probably has something to do with the fact that my program looks at the maximum number of sectors per request that the device will support, and uses that as the default block size for I/O operations — meaning that the card was simply giving back the wrong sector data for the first sector in each operation.) It has survived 19,689 read/write cycles in total so far.
Sample #4’s first error was a 64-sector wide data verification error during round 12. It continued on without any further errors until round 1,914, when it began following the pattern of poor quality flash: large numbers of bit flips across a growing number of sectors. It also began to experience a number of I/O errors. My program deals with this by either retrying the operation or resetting the reader — however, it would frequently stop responding to commands after the reader had been reset, which would require me to manually reset the card (e.g., by removing it from the card reader and reinserting it). After one particular reset during round 2,534, however, it simply got to the point where even a manual reset wouldn’t get it working again. By that point, it had suffered errors over 36% of the total sectors on the card. Here’s what this card’s progression looked like:
- Sample #5’s first error was a series of bit flips affecting two sectors during round 318. It kept going with only a few errors until it got to round 1,271 — at which point the number of bad sectors started accelerating. During round 1,406, it decided to stop responding to commands altogether.
Sample #6’s first error was a 10-sector wide bit flip error during round 1. This continued to get progressively worse over subsequent rounds. At some point during round 1,213, it stopped responding to commands altogether. By that point, it had suffered errors over more than 19% of the total sectors on the card. Here’s what this card’s progression looked like:
My overall opinion on these cards? Don’t buy them. They’re garbage. They perform terribly, their capacities are inconsistent, and 4 of the 6 started running into issues before hitting 20 read/write cycles, and the fifth only made it a few hundred read/write cycles before running into issues. Only one of them managed to make it past the 2,000 read/write cycle mark without issues. Don’t waste your money on them.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Reletech 32GB
- Obtained from: AliExpress
- Price paid: $2.99
- Advertised capacity: 32GB
- Logical capacity: 31,266,439,168 bytes
- Physical capacity: 31,266,439,168 bytes
- Fake/skimpy flash: Skimpy (2.29% skimp)
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10, U3, A1
- CID data:
- Manufacturer ID:
0xfe
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344313647
(ASCII:SD16G
) - Product revision:
0x20
- Manufacturer ID:
Discussion
In early 2024, AliExpress started running sales where items — seemingly from a single seller — were priced at either $1.99, $2.99, or $3.99, and you were allowed to purchase any combination of 3-10 items…I think per day? This caught my attention, so I looked through and found a few brands of microSD cards that I hadn’t seen before, including this one.
The product packaging was a little unusual, in that it had a mixture of English and French…and an office address in Germany. This leads me to believe that they wanted buyers to think that this was a North American or European brand — but then someone ruined the illusion by slapping a sticker on the back that says “Shenzhen Guanlin International Trade Co.,Ltd”. On the bright side, at least this particular card isn’t fake flash. They do have some bigger sizes, and the prices on those scale up with size, so I’m guessing that those aren’t fake flash either. Who knows, I might have to try those out sometime.
I’ve only tested one sample so far, but performance was just “meh”. Sequential read speeds were a little above average, while sequential write speeds were pretty well below average. Random read and write speeds were just average. While this was good enough to qualify for the Class 10 mark, it fell well short of the 30MB/sec write speeds required for the U3 mark, and well short of the 500 random write operations per second required for the A1 mark. Perhaps this card would have done better had it been tested under proper conditions — but somehow I doubt it.
Endurance tests for all three samples are still ongoing:
- Sample #1’s first error was a four-sector wide address decoding error during round 1,523. It has endured 6,548 read/write cycles in total so far.
- Sample #2’s first error was also a four-sector wide address decoding error during round 1,700. It has survived 4,978 read/write cycles in total so far.
- Sample #3’s first error was an address decoding error, that affected just two sectors, during round 4,011. It has survived 5,000 read/write cycles in total so far.
Side note: Samples #2 and #3 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. I’ve also added code to my program to detect and mitigate these types of errors.
November 10, 2024 (current number of read/write cycles is updated automatically every hour)
Samsung EVO Plus 32GB
- Obtained from: Amazon
- Price paid: $11.99
- Advertised capacity: 32GB
- Logical capacity: 32,010,928,128 bytes
- Physical capacity: 32,010,928,128 bytes
- Fake/skimpy flash: No
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x1b
* - OEM ID:
0x534d
(ASCII:SM
)* - Product name:
0x4542315154
(ASCII:EB1QT
) - Product revision:
0x30
- Manufacturer ID:
* This manufacturer ID/OEM ID is well known to be associated with Samsung.
Discussion
Samsung is a pretty well known name in the electronics industry, and flash memory is no exception. I purchased this one because I wanted to have a few legitimately obtained, name brand cards in my collection to compare the AliExpress samples to. I would like to have a couple more samples to test, but these cards are a bit more expensive than many of the others in my collection and it’ll have to wait until I can spare the money to buy some more.
One thing of consequence that I’ll note: Samsung is one of two mainstream brands (of the ones I evaluated) whose flash was neither fake nor skimpy (Lexar being the other). Both of the Samsung cards in my collection currently are 32GB cards, and both offered at least 32 billion bytes of user space. Many of the other name brands — including Kioxia, SanDisk, and Kingston — provided cards that were all skimpy, so I was pleasantly surprised to see that Samsung was not.
Performance-wise, I was actually a bit disappointed. Sequential read speeds were slightly above average, but all of the other scores were just…average. For such a well-recognized brand, I would have expected better. It did, however, perform well enough to qualify for the Class 10 and U1 marks that it carried. I will note, however, that Samsung seems to be phasing out this particular version of the EVO Plus. The new version (see the Samsung EVO Plus 64GB) seems to have a more simplistic design (in terms of both the packaging and the card artwork) and sports faster speeds.
All three samples are currently undergoing endurance testing:
- Sample #1 has done pretty well. As of this writing, it has gone 11,654 read/write cycles and has not yet experienced any errors.
- Sample #2 has also done pretty well — it has survived 7,913 read/write cycles and has not yet experienced any errors.
- Sample #3’s first error was a four-sector wide address decoding error during round 1,416; it has survived 7,202 read/write cycles total so far.
My conclusion: this not a bad card at all. In terms of performance, it’s about average — and about on par with the SanDisk Ultra 32GB. (The SanDisk smoked it in random read speeds, but the Samsung has fared much better in endurance tests.) The only problem? Like I said, Samsung seems to be phasing out this card — so it may get more difficult to find as time goes on.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Samsung EVO Plus 64GB
- Obtained from: AliExpress
- Price paid: $3.99
- Advertised capacity: 64GB
- Logical capacity: 64,088,965,120 bytes
- Physical capacity: 64,088,965,120 bytes
- Fake/skimpy flash: No
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: Class 10*, U1, V10, A1
- CID data:
- Manufacturer ID:
0x1b
** - OEM ID:
0x534d
(ASCII:SM
)** - Product name:
0x4543315335
(ASCII:EC1S5
) - Product revision:
0x30
- Manufacturer ID:
* The Class 10 mark appears on the package, but does not appear on the card itself.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with Samsung.
Discussion
I’m not 100% sure why I decided to buy these. I think that it might have been because of the sale that AliExpress was running on these, and I figured that it might make a good substitute for having three of the EVO Plus 32GB’s (before I decided to buy two more of them). Regardless, it looks like Samsung has phased out the particular version of the EVO Plus that I had previously purchased in favor of this version.
With a skimp rating of -0.14%, Samsung continued their reputation here of being one of the only name-brands that has not skimped on storage space.
The package advertises that this card gets transfer speeds of “up to 130MB/s”. Of course, it doesn’t specify whether that’s referring to read speeds or write speeds, but I think it’s pretty obvious (to me, at least) that it’s referring to read speeds. It managed to meet that expectation — and even go a little bit beyond it. All three had sequential read speeds that came just shy of two standard deviations above average. Random read scores were more than one standard deviation above average, and random write scores were above average. Sequential write scores, however, were slightly below average. These metrics are good enough for the U1 and V10 marks that it carries — and the Class 10 mark on the package — but not quite good enough for the A1 mark (as that requires a random write speed of at least 500 writes per second). Perhaps they would have met the mark had they been tested under the right conditions. I’m curious to see how the other two samples will perform.
Endurance tests for all three cards is still ongoing:
- Sample #1 has survived 4,710 read/write cycles and has not yet experienced any errors.
- Sample #2’s first error was a four-sector wide address decoding error during round 725; it has survived 3,547 read/write cycles in total so far.
- Sample #3 experienced a 6,400-sector wide data verification error during its very first round of endurance testing. It has survived 3,514 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Samsung PRO Endurance 32GB
- Obtained from: Amazon
- Price paid: $6.99
- Advertised capacity: 32GB
- Logical capacity: 32,044,482,560 bytes
- Physical capacity: 32,044,482,560 bytes
- Fake/skimpy flash: No
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10*, U1, V10
- CID data:
- Manufacturer ID:
0x1b
* - OEM ID:
0x534d
(ASCII:SM
)* - Product name:
0x4a42315135
(ASCII:JB1Q5
) - Product revision:
0x30
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to be associated with Samsung.
Discussion
This is one I purchased because — I think — I wanted to see how “high endurance” cards perform compared to their contemporary (low endurance?) cousins.
As I stated above, Samsung is a pretty well-known player in the electronics industry, and their SD cards are no exception. And, as with the Samsung EVO Plus, it’s nice to see that Samsung didn’t skimp on storage — in fact, this one is slightly larger than the EVO Plus.
Performance-wise, this card did well on read tests, but I was a little disappointed by write performance. All three samples got above average sequential read and random write speeds, and scored more than one standard deviation above average on random read tests, but got below average sequential write speeds. It did well enough to qualify for all of the marks that appeared on it (nearly by a factor of 3), but when compared to the other name-brand cards I tested, it did worse on the sequential write test, and only average on the random write test.
All three cards are still undergoing endurance testing:
- Sample #1 has survived 13,481 read/write cycles so far. It experienced data verification failures earlier on, but I was able to chalk those errors up to issues with my code. The first errors that I wasn’t able to attribute to code issues happened during round 3,688.
- Sample #2 has survived 4,342 read/write cycles so far and has not yet experienced any errors.
- Sample #3 has survived 7,426 read/write cycles so far and has not yet experienced any errors.
So just how long should this card last? If we look at Samsung’s product page for this card, they have a footnote where they list the rated endurance 17,520 hours of Full HD video at 26Mb/sec, which translates to about 205TB, or 6,397 read/write cycles. Sample #1 only made it a little over halfway there before it experienced its first error — which admittedly makes me a little disappointed. Hopefully the other two will fare better.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDian Extreme PRO 128GB
- Obtained from: AliExpress
- Price paid: $5.22
- Advertised capacity: 128GB
- Logical capacity: 134,218,776,576 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x4150505344
(ASCII:APPSD
) - Product revision:
0x00
- Manufacturer ID:
Discussion
SanDian is a name that came up fairly frequently in my AliExpress searches, and it was pretty apparent that they were trying to rip off SanDisk — from the product lineup names (“Ultra”, “Extreme”, “Extreme PRO”), to the similar visual design (with the red/black stripes), to the logo (which copies the styled “nD” from SanDisk’s logo). Seeing as how they had several options to choose from, I decided to order a few of each one — in the 128GB and 1TB denominations. However — and I’m going to bury the lead here — they didn’t hold a candle to SanDisk (at least so far).
Initially I was going to lump them into the “off-brand” category; however, given just how closely they’re copying SanDisk’s design, I decided to re-categorize them as knockoffs.
I found it interesting that these cards came in a package that appeared to be for a USB cable rather than the normal clamshell packaging that most SD cards come in.
This is another instance of a seller who set the manufacturer ID and OEM ID to all zeroes to mask their identity and/or the identity of whoever manufactured these cards for them. If the remainder of the CID data is to be believed, then it would mean that these cards were over 6 years old by the time they made it to me. I did manage to find a SanDian store on AliExpress, but their front page made it appear that they were selling women’s clothing — and to boot, they had no actual products listed at the time I looked. This might mean that the SanDian name is being retired (and/or the seller has gone out of business) and that sellers who purchased their cards are simply trying to offload their remaining inventory.
Another thing I found interesting was that physical capacity differed between the three samples. Honestly, I’m at a loss to explain this.
Performance was pretty abysmal, with all metrics being well below average. Even when compared to other fake flash cards in my collection, scores were below average — with the exception of sample #1’s sequential read speed (which was only slightly above average) and sample #2’s random read speed (which was just shy of one standard deviation above average). Performance was not good enough to qualify for any of the speed class markings this card carried. I’ll add my standard “perhaps this card would have performed better if it had been tested under proper conditions” disclaimer, but I highly doubt it would have done much better. Honestly, I would have expected more from a card labeled “Extreme PRO”. Much more. But then again, this is a knockoff brand.
On the endurance front, things are not looking good here either. None of the three samples made it 2,000 read/write cycles — or even 1,000 read/write cycles — before encountering errors.
Sample #1’s first error was a series of bit flip errors affecting two sectors during round 102. It made it 869 read/write cycles before it decided to stop responding to commands. By this point, it had been struggling to stay alive: over 40% of the sectors on the device had been flagged as “bad”, and it went through a couple different phases: one where it disconnected itself from the reader multiple times a day (and had to be unplugged and plugged back in), and one where it would experience long strings of I/O errors before just deciding to work normally again. Finally, though, during round 870, it disconnected itself from the reader and refused to start working again when reconnected — at that point, I decided to declare it “dead”.
Here’s what Sample #1’s progression looked like:
Sample #2’s first error was a series of bit flip errors affecting about 3,400 sectors during round 521. The problem became progressively worse over the following rounds of testing, reaching the point where about 4.27% of the sectors on the device had experienced errors. It finally stopped responding to commands during round 619. Here’s the graph of what this progression looked like:
Sample #3’s first error was a series of bit flip errors during round 440. Like the other two, it slowly deteriorated to the point where over half the sectors on the device had been flagged as “bad”. Here’s what the progression for this sample looked like:
My overall assessment of these cards? Don’t buy them. They perform horribly, not a single one made it even halfway to my 2,000 read/write cycle goalpost, and they’re fake flash to boot. With a little bit of digging, you can find cheaper name-brand cards that are more reliable, have greater capacity, and have way better performance. (Case in point: the Samsung EVO Plus 64GB.)
November 4, 2024
SanDian Extreme PRO 1TB
- Obtained from: AliExpress
- Price paid: $6.62
- Advertised capacity: 1TB
- Logical capacity: 1,072,694,296,576 bytes
- Physical capacity: 29,943,033,344 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x4150505344
(ASCII:APPSD
) - Product revision:
0x00
- Manufacturer ID:
Discussion
There’s not much to say about this card that is going to be different than the 128GB version. Like its smaller sibling, this card was disappointing at best.
Performance metrics were well below average and were only marginally better than the 128GB version — and, like the 128GB version, were not good enough to merit any of the performance marks that it carried.
Like many of the low-quality cards I’ve tested, sample #1 started experiencing errors after only a few read/write cycles, and the number of errors only increased as time went on. It was declared dead after 50% of its sectors had been flagged as bad. Here’s what the graph of this card’s progression looked like:
Sample #2’s first error was a data loss error during round 663. It continued to progressively degrade until it got to just shy of the 10% failure mark, at which point it stopped responding to commands. Here’s what the graph of this card’s progression looked like:
Sample #3’s first error was a 32-sector wide data loss error during round 24. It survived a total of 1,938 read/write cycles before it crossed the 50% failure threshold (though it took a number of manual resets to convince it to keep working up to that point — which is part of the reason why it lasted longer than the other two samples). Here’s the graph of this card’s progression:
So — my overall conclusion? They’re fake flash, they performed below average in every metric, and they couldn’t go more than a few hundred read/write cycles before showing issues. They’re trash; don’t buy them.
November 4, 2024
SanDisk Extreme 32GB
- Advertised capacity: 32GB
- Protected area: 83,886,080 bytes
- Fake/skimpy flash: Skimpy (0.27% skimp)
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product revision:
0x80
- Manufacturer ID:
* This manufacturer ID/OEM ID combination are pretty well known to be associated with SanDisk.
Card # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | Amazon | AliExpress | AliExpress | N/A |
Price paid | $10.49 | $9.70 | $9.70 | $9.96 |
Logical capacity | 31,914,983,424 bytes | 31,902,400,512 bytes | 31,902,400,512 bytes | 31,906,594,816 bytes |
Physical capacity | 31,914,983,424 bytes | 31,902,400,512 bytes | 31,902,400,512 bytes | 31,906,594,816 bytes |
Fake/skimpy flash | Skimpy (0.27% skimp) | Skimpy (0.30% skimp) | Skimpy (0.30% skimp) | N/A |
Adjusted skimp | 0.0035% | 0.04% | 0.04% | 0.03% |
Product name | 0x534d333247 (ASCII: SM32G ) | 0x534e333247 (ASCII: SN32G ) | 0x534e333247 (ASCII: SN32G ) | N/A |
Manufacture date | Apr 2020 | Sep 2023 | Sep 2023 | N/A |
Serial number | 0x5340b8ea | 0xfb233772 | 0xfb233938 | N/A |
Sequential read speed (MB/sec) | 76.73 | 126.87 | 151.46 | 118.35 |
Sequential write speed (MB/sec) | 46.14 | 49.25 | 50.14 | 48.51 |
Random read speed (IOPS/sec) | 2,097.00 | 2,668.37 | 2,606.13 | 2,457.17 |
Random write speed (IOPS/sec) | 339.00 | 452.93 | 449.49 | 413.81 |
Read/write cycles to first error | 5,215 | 74 | 70 | 1,786 |
Read/write cycles to 0.1% failure threshold | 5,215 | Not yet determined | Not yet determined | 5,215 |
Read/write cycles to complete failure | 5,215 | Not yet determined | Not yet determined | 5,215 |
Total days to complete failure | 160 | Not yet determined | Not yet determined | 160 |
Card reader used | 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 |
Discussion
Ok, it’s time to move on to one of my favorite brands.
Yes, I’m biased in favor of SanDisk. I’ve been using their microSD cards in some of my other projects for years (specifically, the SanDisk Ultra, usually the 16GB size) and have found them to be pretty rock-solid. That said, I wanted to try to be objective here. Additionally, before starting this project, my only experience was with the Ultras — I hadn’t used the Extremes or the Extreme PROs.
I’ll note here that I ordered these cards in different batches. The first batch came from Amazon, and consisted of one of each of the SanDisk Extreme and SanDisk Extreme PRO, in both the 32GB and 64GB sizes. The second batch came from AliExpress, and consisted of two each of the SanDisk Extreme and SanDisk Extreme PRO, in the 32GB size. Why order different sizes? Because SanDisk advertises different maximum speeds between the two. This version is supposed to get up to 100MB/sec read speeds, and 60MB/sec write speeds. Additionally, the 64GB model had the A2 mark, while the 32GB model had the A1 mark instead.
I think I got slightly different versions from the two sources: the version I got from Amazon has a product name of SM32G
, while the two I got from AliExpress have a product name of SN32G
. There’s also a noticeable difference in performance between the two: sample #1 only got about 3/4 of the way to the 100MB/sec mark, but samples #2 and #3 went well past it. (How did they do it? SanDisk apparently has some tricks up their sleeve — see the discussion on the SanDisk Extreme PRO 64GB for more info.)
How does this stack up against the other cards I tested? All three samples got above average scores in all performance metrics. Samples #2 and #3 got sequential read and sequential write scores that were more than one standard deviation above average. Sample #3’s sequential read speeds were actually more than two standard deviations above average. Sample #2 also got a random read speed that was more than one standard deviation above average.
This card carries the U3, V30, and A1 markings on it. The results I got are good enough to satisfy the requirements of the U3 and V30 marks; however, the A1 mark requires a random write speed of at least 500 IOPS/sec, and none of these samples met that requirement. Again, I’ll give my standard disclaimer of “perhaps this card would have done better had it been tested under proper conditions”. The two AliExpress samples were close enough to this mark that this could actually be true.
Endurance tests for two of the three cards are still ongoing:
- Sample #1 was doing great until the circuit breaker — to which the host machine was attached — tripped. After restoring power, all of the other cards attached to this machine resumed their testing just fine; however, this one decided that it was done. Admittedly, this made me a little sad, as this particular card had not experienced any errors up until that point. As I mentioned with the SanDisk Ultra 32GB’s, embeddedTS once did similar stress testing of some SanDisk cards and noted that they tend to be sensitive to brownouts — and with the way some of these SanDisk cards are going, I’m forced to agree.
- Sample #2 experienced an address decoding error after only 74 read/write cycles. It seems like it’s been particularly susceptible to address decoding errors — it experienced eight different ones over the first 1,031 read/write cycles. It has survived 7,583 read/write cycles in total so far.
- Sample #3 experienced an address decoding error after just 70 read/write cycles. It also seems like it’s been susceptible to address decoding errors, having experienced five different ones errors over the first 1,083 read/write cycles. It has survived 7,489 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk Extreme 64GB
- Advertised capacity: 64GB
- Fake/skimpy flash: Skimpy (0.21% skimp)
- Protected area: 134,217,728 bytes
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product name:
0x534e363447
(ASCII:SN64G
)
- Manufacturer ID:
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | Amazon | AliExpress | AliExpress | N/A |
Price paid | $10.43 | $9.60 | $9.60 | $9.88 |
Logical capacity | 63,864,569,856 bytes | 63,887,638,528 bytes | 63,887,638,528 bytes | 63,879,948,970 bytes |
Physical capacity | 63,864,569,856 bytes | 63,887,638,528 bytes | 63,887,638,528 bytes | 63,879,948,970 bytes |
Fake/skimpy flash | Skimpy (0.21% skimp) | Skimpy (0.18% skimp) | Skimpy (0.18% skimp) | Skimpy (0.19% skimp) |
Adjusted skimp | 0.0019% | -0.03% | -0.03% | -0.019% |
Product revision | 0x86 | 0x85 | 0x85 | N/A |
Manufacture date | Sep 2023 | Sep 2023 | Sep 2023 | N/A |
Serial number | 0xd84929ad | 0xfea61ca2 | 0xfea61c88 | N/A |
Sequential read speed (MB/sec) | 85.94 | 165.70 | 159.05 | 136.90 |
Sequential write speed (MB/sec) | 51.68 | 69.00 | 74.29 | 64.99 |
Random read speed (IOPS/sec) | 3,334.23 | 2,910.07 | 2,795.22 | 3,013.17 |
Random write speed (IOPS/sec) | 293.81 | 640.39 | 1,154.36 | 696.19 |
Read/write cycles to first error | 1,269 | Not yet determined | 2,955 | 2,112 |
Read/write cycles to 0.1% failure threshold | 5,505 | Not yet determined | Not yet determined | 5,505 |
Read/write cycles to complete failure | 5,505 | Not yet determined | Not yet determined | 5,505 |
Total days to complete failure | 223 | Not yet determined | Not yet determined | 223 |
Card reader used | SanDisk MobileMate | JJC CR-UTC4AC | JJC CR-UTC4AC | N/A |
Package front | N/A | |||
Package back | N/A | |||
Card front | N/A | |||
Card back | N/A |
* This manufacturer ID/OEM ID combination is pretty well known to be associated with SanDisk.
Discussion
Continuing my (hopefully objective) evaluation of SanDisk cards, I purchased both the 32GB and the 64GB versions of this card. As I alluded to earlier, I purchased the 64GB version for a very particular reason.
SanDisk has a “gimmick” with some of their cards: they’re UHS-I cards, but SanDisk advertises speeds that are beyond what should be possible under the UHS-I spec. Under UHS-I, the maximum clock speed for an SD card is 208MHz, and SD cards have four lines for transferring data — which means that the maximum possible speed should be 832Mbit/sec, or 104MB/sec. However, this card advertises that it can get read speeds of up 170MB/sec and write speeds of up to 80MB/sec. I don’t know exactly how they do this, but if you look closely at the package, there’s an asterisk: it requires a “compatible device capable of reaching such speeds”. There’s also a note on the front of the package that says “Compatible with SanDisk Professional PRO-READER SD and microSD to achieve stated read speeds”. I suspect that these card readers have some mechanism to detect whether the card is one that should support these higher speeds; if they do, I suspect that the reader simply overclocks the card to get those speeds.
I don’t have one of the SanDisk Professional PRO-READER SD or microSD readers; however, I do have several SanDisk MobileMate microSD readers — and on the package, it says — quite prominently — “Enables SanDisk enhanced UHS-I microSD card speeds”. This should mean that I should be able to use this reader with this card and get the speeds they advertise (or close to it), right? Well…nope. Actual read/write speeds only got about halfway to the maximum stated on the package.
Compared to the other cards in my collection, sequential read and sequential write speeds were above average, with sequential write speeds being more than one standard deviation above average. Random read speeds were more than one standard deviation above average as well; however, random write speeds were slightly below average. Compared to the other name-brand cards that I tested, sequential read and random write speeds were below average. While this is good enough for the U3 and V30 marks that it carries, the A2 mark requires random read speeds of 4,000 IOPS/sec and random write speeds of 2,000 IOPS/sec — and this card fell well short of that.
Side note: no card I’ve tested so far has met the performance thresholds for the A2 mark. To reach the speeds required for the A2 mark requires some pretty advanced features of the SD spec, which probably requires hardware beyond what I have. However, this card’s random write speeds weren’t even good enough for the A1 mark — and seeing as how I have other cards in my collection that did meet the threshold for the A1 mark, I doubt that it would have performed well enough for the A2 mark even if it had been tested under the right conditions.
Sample #1 was doing fairly well for quite some time; however, at some point I had to shut down the host machine so that I could install some new equipment. When I powered the host machine back up, the card would no longer respond to commands. This isn’t helping the whole “SanDisk cards are prone to fail when subjected to brownout” theory — but at the same time, this card wasn’t doing anything when it was disconnected, and it had been working just fine right before then.
Endurance tests for samples #2 and #3 are still ongoing:
- Sample #2 has survived 7,981 read/write cycles so far and has not yet experienced any errors.
- Sample #3’s first error was a 6-sector wide address decoding error during round 2,956. It has survived 5,272 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk Extreme PRO 32GB
- Advertised capacity: 32GB
- Logical capacity: 31,914,983,424 bytes
- Physical capacity: 31,914,983,424 bytes
- Fake/skimpy flash: Skimpy (0.27% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.0035%
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product name:
0x5350333247
(ASCII:SP32G
) - Product revision:
0x80
- Manufacturer ID:
* This manufacturer ID/OEM ID combination is pretty well known to be associated with SanDisk.
Card # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | Amazon | AliExpress | AliExpress | N/A |
Price paid | $12.63 | $8.55 | $8.55 | $9.91 |
Serial number | 0x7a879790 | 0x8958014d | 0x87b80078 | N/A |
Manufacture date | Jun 2023 | Mar 2023 | Mar 2023 | N/A |
Sequential read speed (MB/sec) | 88.36 | 87.23 | 88.05 | 87.88 |
Sequential write speed (MB/sec) | 54.35 | 53.93 | 53.69 | 53.99 |
Random read speed (IOPS/sec) | 1,867.13 | 1,882.37 | 1,830.30 | 1,859.93 |
Random write speed (IOPS/sec) | 424.56 | 442.15 | 430.39 | 432.37 |
Read/write cycles to first error | 5,188 | 117 | 155 | 1,820 |
Read/write cycles to 0.1% failure threshold | Not yet determined | Not yet determined | Not yet determined | Not yet determined |
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 | 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 |
Discussion
In addition to the SanDisk Extremes, I wanted to test out some SanDisk Extreme PROs as well to see if there was any significant difference between the two.
Like the SanDisk Extreme 32GB, this card doesn’t make any extravagant speed claims — just “speeds” (it doesn’t specifically call out read or write speeds) of up to 100MB/sec. However, unlike the Extreme 32GB, I did not receive different models from Amazon vs. AliExpress — both versions had their product name set to SP32G
. All performance metrics for all three samples were above average, with sequential write speeds — again, on all three samples — being more than one standard deviation above average. Sequential read/write speeds and random write speeds were slightly better than SM32G, although random read speeds were worse. Compared to the SN32Gs, however, read speeds (both sequential and random) were considerably worse, and write speeds (both sequential and random) were on par. Compared to the other name-brand cards that I tested, sequential read speeds were slightly below average, but all other metrics slightly better. Performance was good enough to merit the U3 and V30 marks; however, the A1 mark requires a write performance of at least 500 IOPS/sec, and all three samples fell a little short here. This is going to be another case where I’ll throw in my standard disclaimer: these cards may have done better here if they had been tested under proper conditions. They came close enough to the 500 IOPS/sec mark that this might actually be true.
Endurance tests for all three cards are still ongoing:
- Sample #1 did make it past the 2,000 read/write cycle mark without experiencing any errors; its first error was an eight-sector wide address decoding error during round 5,189. It has survived 11,489 read/write cycles in total so far.
- Sample #2 only survived 117 read/write cycles before experiencing an address decoding error. It has survived 10,280 read/write cycles so far.
- Sample #3 only survived 155 read/write cycles before also experiencing an address decoding error. It has survived 10,275 read/write cycles so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk Extreme PRO 64GB
- Advertised capacity: 64GB
- Logical capacity: 63,864,569,856 bytes
- Physical capacity: 63,864,569,856 bytes
- Fake/skimpy flash: Skimpy (0.21% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 0.0019%
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product name:
0x5352363447
(ASCII:SR64G
) - Product revision:
0x86
- Manufacturer ID:
* This manufacturer ID/OEM ID combination is pretty well known to be associated with SanDisk.
Sample # | 1 | 2 | 3 | Average |
---|---|---|---|---|
Obtained from | Amazon | AliExpress | AliExpress | N/A |
Price paid | $12.99 | $10.63 | $10.63 | $11.42 |
Manufacture date | Sep 2023 | Oct 2023 | Oct 2023 | N/A |
Serial number | 0xa5f89e85 | 0xd1e25004 | 0xd1024e86 | N/A |
Sequential read speed (MB/sec) | 86.43 | 87.19 | 84.86 | 86.16 |
Sequential write speed (MB/sec) | 60.34 | 52.56 | 62.71 | 58.54 |
Random read speed (IOPS/sec) | 2,023.75 | 1,755.97 | 1,834.40 | 1,871.37 |
Random write speed (IOPS/sec) | 349.67 | 298.88 | 394.89 | 347.81 |
Read/write cycles to first error | 2,034 | 6,356 | 3,100 | 3,830 |
Read/write cycles to 0.1% failure threshold | Not yet determined | 6,356 | 3,100 | 4,728 |
Read/write cycles to complete failure | Not yet determined | 6,356 | 3,100 | 4,728 |
Total days to complete failure | Not yet determined | 128 | 125 | 127 |
Card reader used | 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 |
Discussion
As with the SanDisk Extreme 64GB, this card makes some pretty extravagant performance claims — which is why I got it. This one’s claims are even more extravagant than the SanDisk Extreme 64GB — it claims you can get read speeds of up to 200MB/sec and write speeds of up to 90MB/sec.
Before I talk about performance, I want to talk a little bit about the card reader I used for this card: the JJS CR-UTC4AC. JJS doesn’t specify which chip they use, but some deduction can tell us which one they probably used. The reader gives its vendor ID as 0x05e3
and its product ID as 0x0764
. Vendor ID 0x05e3
belongs to Genesys Logic, Inc. The Linux USB project maintains a list of known vendor ID/product ID combinations; however, this list doesn’t have an entry for product ID 0x0764
. We’re not finished yet, however.
If we go to Genesys Logic’s website and look at the list of the card reader controllers that they offer, we see that they offer — as of this writing — 20 different options:
We can filter out some of these options based on what we know:
- The last two options — the GL9750 and the GL9755 are PCI Express (not USB), so we can knock them off the list.
- The three options directly above that — the GL835, GL835T, and GL892S — are only USB 2.0, so we can knock those off the list.
- The GL3227E and GL3224E are eMMC controllers, so we can knock those off the list.
- The GL3232, GL3232S, GL3213L, and GL3233T are all single-LUN readers, so we can knock them off the list.
- UHS-II was added in version 4 of the SD card specification. The GL3230, GL3231, GL3223, GL3224, GL3224L, and GL3235 only support version 3 of the SD card spec, so we can knock those off the list.
- If we pull up the product page for the GL3239, it only mentions support for version 1.0, 1.1, 2.0, and 3.0 of the SD specification — no mention of version 4.0, which means we can knock this one off the list as well.
This leaves us with only two options: the GL3230S and the GL3231S. The GL3230S is a controller that supports a wide array of memory card types: not just SD/MMC, but also CompactFlash and Memory Stick (and its many derivatives). The GL3231S, on the other hand, only supports SD/MMC (and their derivatives). In addition, the GL3230S is a 4-LUN chip, while the GL3231S is a 2-LUN chip. It’s been my experience that multi-LUN card readers generally present all of their LUNs to the host as soon as it’s plugged in (regardless of whether or not there’s a card plugged into it) — and these readers only present two to my system. (Additionally, the GL3230S is probably more expensive than the GL3231S — and JJS probably wouldn’t have paid extra for those extra LUNs unless they planned to actually use them.)
Based on this, I think it’s probably safe to say that these readers use the GL3231S.
Why all the detective work? Well…if you look at the product page for this reader, there’s a statement that stands out to me. It’s even in the very first paragraph on the page:
Now…you could make the argument that this statement is only saying that it supports the card itself — not the enhanced transfer rates that this card offers. But if that’s the case, why bother making that statement at all? Without the enhanced transfer rates, the SanDisk Extreme cards are just regular SD cards — and they don’t bother to call out any other SD cards by name. To me, this means that this reader should support the enhanced transfer rates offered by the SanDisk Extreme cards. (I’m also choosing to believe that it supports the SanDisk Extreme PRO cards as well.)
But…the performance measurements tell a different story. Sure, all of the measurements were above average, but were far below the maximum speeds advertised on the package. I was, frankly, disappointed.
Of course…this card reader was able to get higher speeds with the Extreme 32GB — even going well past what SanDisk advertised — so it’s not the card reader that’s the issue here. (I have two additional samples in the package waiting to be tested — perhaps I’ll get better results with those two.)
Now…if we look at it for what it is? Like I said, all performance metrics were above average — with write speeds being more than one standard deviation above average — being beaten out only by one of the Kioxia Exceria G2’s. However, when compared to the other name-brand cards I tested, all performance metrics (with the exception of sequential write speeds) were actually below average. Performance was more than enough to merit the U3 and V30 marks, but — as with the SanDisk Extreme 64GB — random write performance was well short of what would have been needed for even the A1 mark, let alone the A2 mark.
Endurance tests for all three samples are still ongoing:
- Sample #1’s first error was an eight-sector wide address decoding error during round 2,034; it has survived 5,206 read/write cycles in total so far.
Sample #2 was doing quite well until I shut down the host machine (so that I could shuffle some equipment around in my server closet). When I powered it back on, it would no longer respond to commands. It had not experienced any other errors up until that point. As an interesting side note, this card currently holds the record for “fastest card during endurance testing”, with an average of about 2.88TiB (3.17TB) written to it per day. (I don’t put too much stock in this, however, because most of the cards I’m testing are artificially slowed down during endurance testing due to the fact that the USB bus is almost always being overloaded — and this card is running on a machine where that’s not the case.)
Because this card was tested on a machine whose USB bus was not constantly saturated, let’s take a look at how well the card performed during endurance testing:
(Side note: my program logs statistics once per minute, and I had about 184,000 data points total. When I tried to do something similar with the SanDisk Industrial 8GB #3, it kept crashing the browser. I opted not to try it again with this one, so you get a graph showing per-hour averages instead.)
From this data, you can see a noticeable dip in performance on April 30th. What happened around this date that caused this to happen? I honestly don’t know. This machine did suffer from a power failure, but that didn’t happen until several days later. However, if you look at the SanDisk Industrial 8GB below, you’ll notice that it suffered a performance dip at about the same time — so it would seem that whatever caused it affected both of them.
- Sample #3 was doing just fine until round 3,101 — when it decided to randomly stop responding to commands — continuing the long streak of SanDisk cards simply giving up the ghost at random and without warning.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk High Endurance 64GB
- Obtained from: Amazon
- Advertised capacity: 64GB
- Logical capacity: 63,864,569,856 bytes
- Physical capacity: 63,864,569,856 bytes
- Fake/skimpy flash: Skimpy (0.21% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 0.0019%
- Speed class markings: Class 10*, U3, V30*
- CID data:
- Manufacturer ID:
0x03
** - OEM ID:
0x5344
(ASCII:SD
) - Product name:
0x5348363447
(ASCII:SH64G
) - Product revision:
0x80
- Manufacturer ID:
* The Class 10 and V30 markings appeared on the card, but did not appear on the packaging.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with SanDisk.
Discussion
At one point in time, I decided that I wanted to try out some “high endurance” cards to see if they really held up better on the endurance tests than other cards. For this, I got both this card and the Samsung PRO Endurance. Initially, I only bought one of each; however, I later decided that I should try to get at least three of each model — at which point I went back and purchased two more of both.
Performance-wise, compared to the other cards I tested, this card did rather well in sequential read/write speeds (with sample #1 getting sequential write speeds that were more than one standard deviation above average), but relatively poorly on random read/write tests. Performance was more than enough to qualify for the Class 10, U3, and V30 markings that it carried. Compared to just the name brand cards, this card performed about average on the sequential write tests, and below average on sequential read and random read/write tests. However, if I stop to think about it for a minute, this makes sense: these cards were probably designed to be used in things like security cameras or dashcams, where video is constantly being recorded to the card and old footage is being overwritten. This type of activity involves a lot of sequential writing, so a card being used for this type of activity benefits from having better sequential write speeds.
Endurance tests are still ongoing for these cards. As of this writing:
- Sample #1’s first error was a 32-sector wide write failure during round 5,402. It has survived 8,663 read/write cycles in total so far.
- Sample #2’s first error was a six-sector wide address decoding error during round 1,547. It has survived 4,906 read/write cycles in total so far.
- Sample #3 suffered an 8-sector wide address decoding error after only 159 read/write cycles. It has survived 4,905 read/write cycles total so far.
The card’s packaging (as well as the product brief on Western Digital’s website) offers up some information on how long this card should be expected to last: it shows “up to 5,000 hours of continuous video recording”. A footnote on the back of the package indicates that this measurement assumes video encoded at 26Mbps — which would come out to 93,600Mb/hour (or 11,700MB/hour). Thus, 5,000 hours of video would consume 58,500,000MB (or 58.5TB) of space. Given the capacity of this device, this comes out to just 916 read/write cycles. This is less than half of the 2,000 read/write cycle target we’re going for (oof), and only 2 out of the 3 samples I tested managed to make it past this point (double oof).
Overall, this is not a bad card in terms of speed — it gets pretty good write speeds and average read speeds — but I’m disappointed when it comes to endurance. Only one of the three managed to make it past the 2,000 read/write cycle mark. On top of that, SanDisk set the bar for “high endurance” pretty low with this card. If you’re going to buy this card, I wouldn’t expect it to last any longer just because it’s a high endurance card.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk ImageMate Pro 128GB
- Obtained from: Walmart
- Price paid: $14.39
- Advertised capacity: 128GB
- Logical capacity: 127,865,454,592 bytes
- Physical capacity: 127,865,454,592 bytes
- Fake/skimpy flash: Skimpy (0.11% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 0.00026%
- Speed class markings: Class 10*, U3, V30, A2
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product name:
0x5352313238
(ASCII:SR128
) - Product revision:
0x86
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to belong to SanDisk.
Discussion
This card was pointed out to me by a Redditor after someone shared this page to r/SBCGaming (thanks, u/_master_!). Seeing as how it was in my price range, I figured “why not?”
My initial impression is that this is simply a rebranded SanDisk Extreme PRO 128GB — just based off the fact that (a) the product name (in the CID data) has the same “SR” prefix as the SanDisk Extreme PRO 64GB, and (b) the product revision (also in the CID data) is the same. In performance tests, it did about the same as the other SanDisk Extreme PRO’s, except for sequential write speeds — where it outperformed all of them, putting it (as of the time of this writing) in the 97th percentile for sequential write speeds.
On the endurance testing front:
- Sample #1 has survived 2,373 read/write cycles so far and has not yet experienced any errors.
- Samples #2 and #3 are still in the package waiting to be tested.
December 5, 2024
SanDisk Industrial 8GB
- Obtained from: Amazon
- Price paid: $8.17
- Advertised capacity: 8GB
- Logical capacity: 7,948,206,080 bytes
- Physical capacity: 7,948,206,080 bytes
- Fake/skimpy flash: Skimpy (0.65% skimpy)
- Protected area: 50,331,648 bytes
- Adjusted skimp: 0.018%
- Flash technology: MLC
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
)* - Product name:
0x5341303847
- Product revision:
0x80
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to be associated with SanDisk.
Discussion
Ok…why did I buy this one? Because I wanted to see what other offerings SanDisk has, but also because I think that at this point, I’m just on a mission to figure out who makes the most reliable microSD cards.
I thought it was interesting that these cards came in a simple plastic case. I’m guessing SanDisk only sells these cards by the tray, and the seller simply repackaged them to sell them individually.
As far as performance goes, this card is almost the definition of the “average” card. Sequential read speeds were slightly above average, while all other performance metrics were right around average. As of the time of this writing, the overall performance score for this card was -0.019 — remember that under my rating system, a score of zero represents a perfectly average score. And, keep in mind that the range of scores (for all cards) was from -1.50 to 1.87 — so a score of -0.019 is about as close to a perfectly average score as you can get. (Technically the Microdrive “Bart Simpson” 16GB got closer to 0 than this one did — with a score of 0.0097 — but this one was the second-closest.)
Endurance tests for two of the three cards are still ongoing. All three samples made it past the 2,000 read/write cycle mark without errors, making it only the third model in my collection to do so — and the first model in my collection to make it past 10,000 read/write cycles without any errors.
- Sample #1’s first error was an unrecoverable read error during round 17,852. It has survived 18,283 read/write cycles so far; however, it’s currently stuck dealing with a long series of unrecoverable read errors and not really making any forward progress. (I should just declare it dead; however, there’s a part of me that says “if I can identify the bad parts of the card and avoid them, then maybe I can get some more life out of this card” — but if the program has to do a reset on the card, it’s taking about 25 hours for the reset to complete just because of how long it takes each read attempt to fail.)
- Sample #2’s first error was a series of write errors during round 19,750 that only seemed to resolve itself when I stopped and restarted the endurance test (even switching card readers didn’t help). However, it really started having issues during round 20,766 — when attempting to read from certain sectors would just result in I/O errors. By this point, I had implemented code to mark off sectors that consistently gave I/O errors, so I decided to simply let this situation play out and see if things would continue as normal after it had worked past those sections of the card. This was a slow process — by the end, it was taking around half an hour per sector to declare a sector “unusable”. However, it ended up being a moot point: after over six weeks of letting this play out, the card decided it had enough and stopped responding to commands.
Sample #3 survived 20,876 read/write cycles; during round 20,877, it got to the point where pretty much all attempts to read from the card would result in I/O errors. I decided to declare the card “dead” at that point.* On an interesting side note, this card is the current recordholder for “most number of read/write cycles completed per day during endurance testing”, at 219.75.
Now…I don’t normally pay much attention to how a card performs during the endurance test. This is because, normally, the card isn’t performing up to its full potential during the endurance test for a couple of reasons:
- Normally, I have two cards plugged in to each card reader — and due to the nature of the SD bus, the reader is splitting its time between the two cards; and
- The USB bus on my testing rigs is constantly saturated: the USB 3 bus allows for up to 5 Gbps (including overhead), which translates to 625MB/sec. The average sequential read speed — across all cards, as of the time of this writing — is about 75MB/sec. This means that I could (theoretically) read from 8 of these cards simultaneously without saturating the USB bus. Well…three of my testing rigs are testing 32 cards simultaneously, and another one is testing 28 cards simultaneously (and that’s only because it ran out of device descriptors, so it couldn’t handle any more card readers plugged into it). This means that on average, I should only able to get about 19-22MB/sec per card during endurance tests.
Well…it just so happens that I have one machine set aside for doing full-speed endurance tests. It only has three card readers plugged into it, and each card reader only has one card plugged in. Sample #3 happened to be one of those cards. So…how well did it perform? Let’s have a look:
(Side note: my program logs statistics once per minute, and I had about 135,000 data points total. I originally tried to insert a graph here that included all of those data points, but it kept crashing the browser. So instead, you get a graph showing per-hour averages.)
From this data, you can see a noticeable dip in performance around April 30th. What happened around that time to cause that? ¯\_(ツ)_/¯ I did have a power failure that affected this machine — but that didn’t happen for several days afterwards. I honestly have no idea what happened to the card or the host machine (if anything) that would have caused this.
As it so happens, Western Digital (who now owns the SanDisk brand) publishes a product brief for these cards. How do my results stack up against what Western Digital advertises? (For the record, the cards I have are model number SDSDQAF3-008G-I.)
First, let’s look at performance. The product brief says that these cards should be able to get up to 80MB/sec in sequential read speeds and 50MB/sec in sequential write speeds. My samples definitely hit 80MB/sec in sequential read speeds, but didn’t make it anywhere close to the 50MB/sec in sequential write speeds that they advertised.
Next, let’s look at endurance. Western Digital says that these cards are supposed to be able to endure 384TBW (terabytes written). (They don’t specifically define what a TB is — whether it’s a terabyte [one trillion bytes] or a tebibyte [1,0244] bytes — but seeing as how they do have footnotes that define 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes, I think it’s reasonable to assume that they’re also using terabytes.) Given the physical user area on the device, this means that the device should be able to endure at least 48,313 read/write cycles. None of the three samples made it even halfway to that mark.
Overall, this card only scored about average in terms of speed. However, it has shined in terms of endurance. If you’re looking for something is going to work reliably for a long time, this is the card to go with. The biggest disadvantage here is that you’re going to be paying for that reliability, as they have a higher price per gigabyte than many of the other cards I purchased. (So far, the Kingston Industrial 8GB has been the worst here, coming in at $1.732 per gigabyte; however, this card came in 4th place. If you take out the two fake flash cards that came in 2nd and 3rd place, then this card came in 2nd place.)
* With some of the other SanDisk cards, I have noted that they have a tendency to self-destruct when subjected to a brownout. This doesn’t appear to be the case with this card — nothing happened (to the best of my knowledge, anyway) that would have created a brownout situation for this card.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
SanDisk Ultra 32GB
- Obtained from: AliExpress
- Price paid: $6.49
- Advertised capacity: 32GB
- Logical capacity: 31,914,983,424 bytes
- Physical capacity: 31,914,983,424 bytes
- Fake/skimpy flash: Skimpy (0.27% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.0035%
- Speed class markings: Class 10, U1*, A1
- CID data:
- Manufacturer ID:
0x03
** - OEM ID:
0x5344
(ASCII:SD
)** - Product name:
0x5344333247
(ASCII:SD32G
) - Product revision:
0x85
- Manufacturer ID:
* The U1 marking appeared on the card, but did not appear on the package.
** This manufacturer ID/OEM ID is pretty well known to be associated with SanDisk.
Discussion
The SanDisk Ultra has been my go-to SD card for a number of years now. I run a farm of single-board computers, and I’ve been primarily using these cards (in the 16GB denomination) as the primary storage device for these devices — and in general, I’ve found them to be cheap and reliable. I’ve had good luck with them, but I wanted to be objective here and make sure that I ran these through the same paces as the other cards in my collection.
Performance-wise, these cards did well in both sequential read and random read/write speeds, but slightly below average in sequential write speeds. Both samples tested so far performed more than one standard deviation above average in random read speeds, with sample #1 performing more than two standard deviations above average. This was enough to merit the Class 10 and U1 markings; however, it fell short of the 500 IOPS/sec of random write performance required for the A1 mark. I’ll throw in my standard “perhaps this card would have done better if it had been tested under proper conditions” disclaimer here — sample #1 was close enough that this may actually be true.
This is another UHS-I card that advertises speeds higher than what should be possible under the UHS-I standard: the package advertises (in Chinese) “speeds up to 120MB/second”. To give this card a fair chance, I tested one of them using one of the SanDisk MobileMate readers, but it didn’t seem to perform significantly better with this reader than it did with the Togconn or JJS readers.
The first error for samples #1 and #2 was an address decoding error. Curiously, both samples died when I plugged new JJS CR-UTC4AC card readers into nearby USB ports — which leaves me wondering if (a) these readers are creating some sort of surge (or brownout) on the USB bus, (b) the particular USB hub where this issue occurred didn’t electrically isolate the USB ports from each other, and (c) the card readers themselves failed to stop the surge from going through to the cards. But that’s just speculation. However, embeddedTS once tested a number of SanDisk cards (though they didn’t specify exactly which model/capacity) and noticed that some of them would fail during a brownout — so perhaps plugging in another reader simply caused a brownout on the USB bus that these cards didn’t like.
Sample #3’s first errors — which occurred during round 395 — were an odd combination: 7 contiguous sectors where the data was shifted by one sector, but also the first four bytes of each sector were all zeroes; followed by 2,048 contiguous sectors where the data was shifted by one sector. It continued for about another 2,800 read/write cycles until it just…stopped working. Nothing especially noteworthy precipitated it — it just decided to stop working during round 3,182. ¯\_(ツ)_/¯
November 4, 2024
SanDisk Ultra 128GB
- Obtained from: AliExpress
- Price paid: $14.58
- Advertised capacity: 128GB
- Logical capacity: 127,865,454,592 bytes
- Physical capacity: 127,865,454,592 bytes
- Fake/skimpy flash: Skimpy (0.11% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 0.00026%
- Speed class markings: Class 10, U1*, A1
- CID data:
- Manufacturer ID:
0x03
** - OEM ID:
0x5344
(ASCII:SD
)** - Product name:
0x5344313238
(ASCII:SD128
) - Product revision:
0x85
- Manufacturer ID:
* The U1 mark appears on the card, but does not appear on the product packaging.
** This manufacturer ID/OEM ID is pretty well known to be associated with SanDisk.
Discussion
I believe I picked up this one after seeing that SanDisk advertised performance differences between the 32 and 64GB versions of both the Extreme and the Extreme Pro, and I wondered if larger sizes of the SanDisk Ultra would show similar performance improvements when compared to its smaller siblings.
As it turns out, the answer was “yes”: this card did significantly better in sequential read speeds, and mildly better in sequential write speeds, than the SanDisk Ultra 32GB. Random read speeds were worse than the 32GB version, while random write speeds were about the same. Overall, two of the three samples got sequential read speeds that were more than two standard deviations above average, while the third came close. Sequential write speeds were right around average, and random I/O speeds (both read and write) were slightly above average.
Endurance tests for all three models are still ongoing. None of the three have made it to the 2,000 read/write cycle mark. Sample #1 is currently expected to get there sometime in March 2025, while samples #2 and #3 are expected to get there sometime in April 2025.
November 4, 2024
Sansumg Pro Plus 2TB
- Obtained from: AliExpress
- Price paid: $4.63
- Advertised capacity: 2TB
- Logical capacity: 2,147,483,648,000 bytes
- Physical capacity: 8,489,271,296 bytes
- Fake/skimpy flash: Fake flash
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID: Unknown*
- OEM ID: Unknown*
- Product name: Unknown*
- Product revision: Unknown*
- Serial number: Unknown*
- Manufacture date: Unknown*
- Sequential read speed (MB/sec): 9.98
- Sequential write speed (MB/sec): 9.07
- Random read speed (IOPS/sec): 574.04
- Random write speed (IOPS/sec): 0.79
- Read/write cycles to first error: 1,970
- Read/write cycles to 0.1% failure threshold: 1,970
- Read/write cycles to complete failure: 1,970
- Total days to complete failure: 45
- Card reader used: SmartQ Single**
- Package front:
- Package back: Not available
- Card front:
- Card back:
* These values are unknown because I didn’t have the idea to dump the card registers until later in this project; by the time I thought to do it, this card had already died.
** I think. Seeing as how this is one of the first cards I tested, I would have only had SmartQ Single’s at that point in time.
Discussion
Before I go any further: yes, “Sansumg” is misspelled. No, it’s not a typo. This is one of the first cards that I bought off of AliExpress, and I spotted the misspelling immediately — in fact, it was the whole reason I ordered it. The makers of this card even went so far as to try to make their logo look like Samsung’s — taking Samsung’s logo and switching the “M” and “N” around.
Being fake flash, this card did about as abysmally as I expected on its performance tests — maybe even worse. All performance metrics were more than one standard deviation below average. This is not a unique distinction — it’s shared by a few other cards in my collection — however, what does make this card stand apart is the fact that it had the lowest score in the sequential read test out of any of the cards I tested. In fact, not only does it not qualify for any of the performance marks that it carries, but it didn’t even meet any single threshold for any of its performance marks.
I was about to be impressed by how long this card managed to last in its endurance tests; however, it failed just shy of the 2,000 read/write cycle mark. It failed pretty suddenly, and just suddenly stopped responding to commands from the system.
November 4, 2024
Somnambulist 128GB
- Obtained from: AliExpress
- Price paid: $3.99
- Advertised capacity: 128GB
- Fake/skimpy flash: Fake flash*
- Protected area: 134,217,728 bytes (inaccessible)
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344313647
(ASCII:SD16G
) - Product revision:
0x20
- Manufacturer ID:
Discussion
Ok, this has to be one of the weirdest trio of cards I’ve reviewed so far.
A number of new brands of questionable flash appeared towards the beginning of 2024, and this was one of them. I imagine that they’re trying to mimic Lexar, since the design mirrors that of the Lexar Blue 633x (including the “633x” mark). But what really made them weird? The fact that all three are different sizes — and none of them is 128GB. Rather, they’re all somewhere between 64GB and 128GB. I would have understood if the CID register indicated that they were 128GB but had turned out to actually be 16GB — in fact, the product name in the CID register is “SD16G”, which I’ve only ever seen associated with 16GB cards — but that wasn’t the case here. They are the size that the CSD register says they are.
On the performance front…well…sample #1 got the lowest sequential read/sequential write scores of any card I’ve reviewed so far — primarily due to the fact that it failed to break even 1MB/sec in either one — and the second worst random read score. Samples #2 and #3 did better, but were still below average in 3 out of the 4 categories — only scoring above average in sequential read speeds.
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 768. It has survived 1,065 read/write cycles in total so far.
- Sample #2’s first error was a string of bit flip errors affecting 120 sectors during round 204. It has survived 1,050 read/write cycles in total so far.
- Sample #3 experienced a 1,152-sector wide data verification error during round 34. It has survived 1,005 read/write cycles in total so far.
On a random side note, it was pointed out that the word “somnambulist” refers to someone who sleepwalks. It definitely felt like there was some sleepwalking involved in the creation of these cards.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
"Sony" 32GB
- Obtained from: AliExpress
- Price paid: $4.66
- Advertised capacity: 32GB
- Logical capacity: 31,266,439,168 bytes
- Physical capacity: 31,266,439,168 bytes
- Fake/skimpy flash: Skimpy (2.29% skimp)
- Protected area: 83,886,080 bytes (inaccessible)
- Speed class markings: Class 10, U1, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x3432
(ASCII:42
) - Product name:
0x5344313647
(ASCII:SD16G
) - Product revision:
0x20
- Serial number:
0x00000378
- Manufacture date: Sep 2023
- Manufacturer ID:
- Sequential read speed (MB/sec): 67.63
- Sequential write speed (MB/sec): 17.57
- Random read speed (IOPS/sec): 1448.45
- Random write speed (IOPS/sec): 273.42
- Read/write cycles to first error: 518
- Read/write cycles to 0.1% failure threshold: 1,399
- Read/write cycles to complete failure: 1,749
- Total days to complete failure: 136
- Card reader used: JJC CR-UTC4AC
- Package front:
- Package back:
- Card front:
- Card back:
Discussion
This is another card that I bought for two reasons: to see if I could find genuine flash and fake flash in the same brand, and to evaluate a knockoff brand. I believe I succeeded on both points here.
Knockoff brands like these usually follow a pretty similar M.O.: they take the name of a brand that’s a pretty well known electronics manufacturer, but who isn’t known for producing flash media (or usually any storage media whatsoever). In this respect, Sony fits this bill. Perhaps they can do this so that it’s harder to disprove that their product is genuine — if there’s no genuine article to compare it to, then it’s harder for someone to say that their product isn’t genuine. That said, I heavily suspected that this card was going to be a knockoff when I ordered it.
This card is another example where the manufacturer set the manufacturer ID to all zeroes, likely in an attempt to mask the manufacturer’s true identity. However, there are a number of cards in my collection that all share the same OEM ID and product ID, including the three Cloudisk cards, one of the Auotkn Extreme 8GB cards, and one of the Bekit 8GB cards — I’m willing to bet that all of these were made by the same manufacturer.
Performance on this card was mediocre overall. Read performance (both sequential and random) and random write performance were all average or slightly below average, while sequential write performance was pretty solidly below average. Compared to the other knockoff cards I evaluated, however, this card actually did quite well: sequential read and random write speeds were more than two standard deviations above average, and sequential write and random read speeds were one standard deviation above average. These scores were enough to merit the Class 10 and U1 markings it carries; however, both random read and random write performance fell short of the threshold for the A1 marking. I honestly don’t think there’s any way that this card would qualify for the A1 marking — and I can say that because I’m not scared of “Sony” coming after me for that comment.
On the endurance front — most of the cards I’ve tested have failed before they reached the 50% (the point where 50% of the sectors on the device have been flagged as “bad” due to verification failures or I/O errors). To this one’s credit (or not? I’m not sure), it kept chugging along right up until it hit that threshold. Don’t get me wrong — this card is still nothing to write home about, especially since it couldn’t go 2,000 read/write cycles without an error…or at all. Here’s what the progression for this card looked like:
November 4, 2024
"Sony" 1024GB
- Obtained from: AliExpress
- Price paid: $5.17
- Advertised capacity: 1024GB
- Logical capacity: 1,073,742,872,576 bytes
- Physical capacity: 31,224,393,216 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: Class 10, U1, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x0050ffffb0
- Product revision:
0x00
- Serial number:
0x12800188
- Manufacture date: Aug 2013
- Manufacturer ID:
- Sequential read speed (MB/sec): 11.83
- Sequential write speed (MB/sec): 10.08
- Random read speed (IOPS/sec): 492.28
- Random write speed (IOPS/sec): 6.01
- Read/write cycles to first error: 359
- Read/write cycles to 0.1% failure threshold: 363
- Read/write cycles to complete failure: 460
- Total days to complete failure: 48
- Card reader used: JJC CR-UTC4AC
- Package front:
- Package back:
- Card front:
- Card back:
Discussion
Like the smaller 32GB sibling, I bought this to see if I could find genuine flash and fake flash in the same brand, as well as to evaluate some knockoff brands. Unsurprisingly, this card turned out to be fake flash — which I heavily suspected would be the case when I ordered it. It was a bit of a surprise that it turned out to have 32GB of space — as opposed to some of the other fake cards I have, which were 4GB and 8GB.
This card did pretty abysmally in terms of performance, falling more than one standard deviation below average on all performance metrics. It even fell well below average when compared to the other knockoff cards I evaluated. It was barely enough to merit the Class 10 and U1 marks that it bore, but it fell well short of the speeds it would need to merit the A1 mark.
Where this card surprised me was on its endurance tests: it only managed to go for 359 read/write cycles before it started showing issues, and only 460 cycles before it stopped responding to commands. This puts it well below average, even when compared to the other knockoff cards I tested, and — as of the time of this writing — the knockoff card that has survived the least number of read/write cycles before failing.
November 4, 2024
SP Elite 32GB
- Obtained from: Amazon
- Advertised capacity: 32GB
- Logical capacity: 31,096,569,856 bytes
- Physical capacity: 31,096,569,856 bytes
- Fake/skimpy flash: Skimpy (2.82% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 2.56%
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x5350434320
(ASCII:SPCC
) - Product revision:
0x12
- Manufacturer ID:
Discussion
3D NAND is a newer flash memory technology where transistors are built up in layers, allowing for greater memory density. In fact, Branch Education did an excellent video on SSDs where they went into how 3D NAND technology works and how it’s produced. Since it’s a newer technology, I wanted to see how it compares to traditional (2D) NAND. This was the first one I found that advertised itself as 3D NAND and was within my budget. Admittedly I’m not very familiar with Silicon Power, but they’re a member of the SD Card Association, so I’ll lump these cards in with the “Name Brand” category.
You might notice the difference in price, as well as the fact that two of them have CID data indicating that they were manufactured in 2009. What I purchased was a single card and a two-pack, as the two-pack was only a few dollars more than the single card. Of course, what Amazon sent me was just two single cards (each in its own packaging) together in an envelope. I believe the two that have their manufacture date set to 2009 were from this pack, but I didn’t keep track of which ones came from the two-pack, so I can’t be 100% sure. Why do they have their manufacture date set to 2009? No clue. But I’m pretty sure the chances that they were actually manufactured in 2009 are next to nil.
Performance on these cards was a little disappointing. Sequential read speeds were above average, but all other metrics were below average. All measurements came in within one standard deviation of average. Is this a factor of the fact that this is a 3D NAND card? No clue — I might have to test some of SP’s other (2D NAND) models to figure that out.
The results of the endurance tests for these cards was also disappointing. All three of them failed in the same way: they simply stopped responding to commands, even though they had been doing quite well in the endurance tests up until that point. None of them made it to the 2,000 read/write cycle mark; sample #3 didn’t even make it to the 1,000 read/write cycle mark before failing.
I dunno — this doesn’t inspire confidence in 3D NAND technology. However, so far they’re my only cards that use 3D NAND. (I guess I don’t know for certain that they use 3D NAND; they could have simply said they were 3D NAND and actually made with 2D NAND.) They’re also the only Silicon Power cards I’ve tested so far — so maybe I need to get some other Silicon Power cards and see if they have the same issue. But so far neither of these inspire me.
November 4, 2024
SP Superior 128GB
- Obtained from: Amazon
- Price paid: $10.97
- Advertised size: 128GB
- Logical size: 124,383,133,696 bytes
- Physical size: 124,383,133,696 bytes
- Fake/skimpy flash: Skimpy (2.83% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 2.72%
- Speed class markings: U3, V30, A2
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x5350434320
(ASCII:SPCC
) - Product revision:
0x20
- Manufacturer ID:
Discussion
After the disappointing results from the SP Elite, I wanted to know if Silicon Power was the issue, if the SP Elite was the issue, or if 3D NAND in general was the issue. To try to narrow down the issue, I picked up these cards and the SP Superior Pro 128GB.
I only have performance results from a single card at the moment…but just based on those results, it looks like this card is going to be slightly better than the SP Elite. Sequential read and random write speeds were similar, while sequential write and random read speeds were improved — about 40% better in sequential write speeds, and about 80% better in random read speeds. In terms of overall performance, this puts it just slightly above average.
Sample #1 is the only one going through endurance testing at the moment, and it has not yet hit the 2,000 read/write cycle mark. It is currently expected to reach this point sometime in January 2025.
Samples #2 and #3 are still in the package waiting to be tested.
November 4, 2024
SP Superior Pro
- Obtained from: Amazon
- Price paid: $13.99
- Advertised capacity: 128GB
- Logical capacity: 124,383,133,696 bytes
- Physical capacity: 124,383,133,696 bytes
- Fake/skimpy flash: Skimpy (2.83% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 2.72%
- Speed class markings: U3, V30, A1
- CID data:
- Manufacturer ID:
0x9f
- OEM ID:
0x5449
(ASCII:TI
) - Product name:
0x5350434320
(ASCII:SPCC
) - Product revision:
0x10
- Manufacturer ID:
Discussion
After the somewhat disappointing endurance test results on the SP Elites, I wanted to see if the issue was more to do with 3D NAND in general, or if it was more to do with SP as a brand — so I picked up some (what turned out to be) SP Superior’s and SP Superior Pro’s.
Offhand, the CID information would seem to indicate that these are just a minor variant of the SP Superior’s — although it’s odd that the product revision went down for this version instead of up. The size is exactly the same, and the performance between the two is pretty similar — only a few MB/sec difference in sequential I/O speeds. Random read speeds are pretty good — putting it over the 80th percentile (as of this writing) — but the other scores are nothing to write home about. But…all of this is just based on one sample. Perhaps the other two samples will fare better.
Endurance tests for sample #1 are still in progress. It has not yet reached the 2,000 read/write cycle mark; it is expected to get there sometime in January 2025.
Samples #2 and #3 are still in the package, waiting to be tested.
November 4, 2024
Transcend 350V 64GB
- Obtained from: Amazon
- Price paid: $11.99
- Advertised capacity: 64GB
- Logical capacity: 62,545,461,248 bytes
- Physical capacity: 62,545,461,248 bytes
- Fake/skimpy flash: Skimpy (2.27% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 2.06%
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x74
* - OEM ID:
0x4a60
(ASCII:J`
)* - Product name:
0x5553445531
(ASCII:USDU1
) - Product revision:
0x20
- Manufacturer ID:
* This manufacturer ID/OEM ID is pretty well known to be associated with Transcend.
Discussion
Transcend is a brand that I hadn’t really considered until I went out and searched for “microSD card reliability” (I keep hoping I’ll show up in the search results…you know, before page 100) and stumbled upon a survey asking people to rank what the most reliable SD card was.
Performance for all three samples was…decent. Sequential read speeds, sequential write speeds, and random write speeds were all less than one standard deviation above average (with the exception of sample #2, whose random write speeds were a bit below average). Random read speeds for all three were more than one standard deviation above average.
Endurance testing for all three samples is still ongoing:
- Sample #1’s first error was a single bit flip, in a single sector, during round 1,447. It has survived 2,278 read/write cycles in total so far.
- Sample #2 has survived 4,067 read/write cycles so far and has not yet experienced any errors.
- Sample #3’s first error was a four-sector wide address decoding error during round 963. It has survived 2,122 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles updates automatically every hour)
WD Purple 32GB
- Obtained from: Amazon
- Price paid: $13.04
- Advertised capacity: 32GB
- Logical capacity: 31,914,983,424 bytes
- Physical capacity: 31,914,983,424 bytes
- Fake/skimpy flash: Skimpy (0.27% skimp)
- Protected area: 83,886,080 bytes
- Adjusted skimp: 0.0035%
- Speed class markings: Class 10, U1
- CID data:
- Manufacturer ID:
0x03
* - OEM ID:
0x5344
(ASCII:SD
) - Product name:
0x5758333247
(ASCII:WX32G
) - Product revision:
0x80
- Manufacturer ID:
* This manufacturer ID/OEM ID combination is pretty well known to be associated with SanDisk.
Discussion
I think this is one I found out about after perusing through SanDisk/Western Digital’s online store and seeing what options they had available. And since I seem to be reviewing everything else of SanDisk’s, why not add this to the mix?
Performance-wise, SanDisk set the bar pretty low on this one — there are no speed claims on the package, and the card itself only bears the Class 10 and U1 markings. It easily met the requirements for both of those markings. All performance metrics came within one standard deviation of average, with sequential write speeds being the worst of the four scores. Overall, it performed about as well as the Samsung EVO Plus 32GB.
All three samples are currently undergoing endurance testing:
- Sample #1’s first error was a two-sector wide address decoding error during round 1,367. It chugged along for quite some time without any further errors. During round 3,064, however, the USB hub — to which its card reader was plugged into — had issues and needed to be reset. When I plugged the hub back in, every other card on this hub immediately started working; however, this card wouldn’t respond to commands, giving us yet another example of a SanDisk card dying suddenly and without warning.
- Sample #2’s first error was a two-sector wide address decoding error during round 1,762. It died the same way sample #1 did — when the USB hub that the reader was plugged into needed to be reset, it decided to give up the ghost. It had been doing just fine right up until then.
- Sample #3’s first error was an address decoding error, affecting four sectors, during round 1,645. And, not wanting to deviate from the pack, it died the same way samples #1 and #2 did — at the same time as when a USB hub needed to be reset.
Side note: All three samples did technically experience earlier errors; however, I’m almost positive that these were device mangling errors and thus not the card’s fault. Therefore, I’ve decided to discard those errors. I’ve since added code to my program to detect and mitigate these types of errors.
Overall, these cards were OK in terms of endurance — lasting an average of 4,296 read/write cycles before failing (as of this writing, the average for all cards is 4,879 read/write cycles), OK in terms of performance, and above average in terms of cost per gigabyte. Personally, I think I’d say “go ahead if you find a good deal on them…but otherwise, don’t bother”.
December 16, 2024
"Xiaomi" 16GB
- Obtained from: AliExpress
- Price paid: $5.38
- Advertised capacity: 16GB
- Logical capacity: 16,106,127,360 bytes
- Physical capacity: 4,026,329,600 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: Class 10, U3, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x0000000000
- Product revision:
0x00
- Serial number:
0x000048bd
- Manufacture date: Jan 2023
- Manufacturer ID:
- Sequential read speed (MB/sec): 18.96
- Sequential write speed (MB/sec): 7.29
- Random read speed (IOPS/sec): 1028.13
- Random write speed (IOPS/sec): 1.48
- Read/write cycles to first error: 0
- Read/write cycles to 0.1% failure threshold: 249
- Read/write cycles to complete failure: 6,618
- Total days to complete failure: 90
- Card reader used: JJC CR-UTC4AC
- Package front:
- Package back:
- Card front:
- Card back:
Discussion
This is another card that I purchased for a couple of reasons: first, because I wanted to see if it was possible to find both fake flash and non-fake flash in the same brand, but also because I wanted to evaluate a few knockoff cards. (For those of you outside of China: Xiaomi is a pretty well known electronics maker in China — many have dubbed it “the Apple of China” — but from what I can tell, they don’t sell microSD cards…or any storage products whatsoever. This seems to be a pretty common M.O. for knockoff media sellers — they will label something using the name of a pretty well known electronics manufacturer, even though the manufacturer they’re knocking off isn’t known for making flash media.)
I purchased two samples: a 16GB and a 2TB. What surprised me is that both samples were fake flash — I expected the 2TB card to be fake, but I didn’t expect the 16GB card to be fake.
Performance metrics were — as to be expected — pretty abysmal. All performance metrics were below average; and with the exception of the random read metric, all performance metrics were more than one standard deviation below average. Scores were not good enough to qualify for any of the performance marks that it bore. Perhaps it would have done better had it been tested under proper conditions, but I highly doubt it.
On the endurance front, this card started having issues almost immediately. During the first round of testing, a 1.8MB “hole” appeared, where reads from sectors in the hole resulted in all zeroes being read back. This hole persisted in size and location during subsequent rounds. Several more such holes (of varying sizes) appeared during subsequent rounds, but did not persist for more than a few rounds. Additionally, data verification failures happened during a few rounds of testing, affecting ranges in size from a few hundred kilobytes to several megabytes. Curiously, however, these issues stopped between rounds 1,599 and 5,239 (with the exception of the original hole discovered during the first round); at this point, the card began to suffer a lot of bit flip errors. It finally failed during round 6,619 — when any attempt to write to the card resulted in an I/O error.
Given that the hole that appeared during the first round of testing — which I’ll call the “origi-hole” — persisted during all rounds of testing, and combined with the fact that all subsequent errors happened after the location of the origi-hole, it could be that the origi-hole marks the end of the intended physical space, and that the remaining space is being used for wear leveling. I haven’t seen any other cards exhibit this kind of behavior. If that’s the case, then the true size of the device would be 3,824,201,728 bytes instead. But…that’s just my guess.
November 4, 2024
"Xiaomi" 2TB
- Obtained from: AliExpress
- Price paid: $5.89
- Advertised capacity: 2TB
- Logical capacity: 2,147,483,648,000 bytes
- Physical capacity: 4,010,738,176 bytes
- Fake/skimpy flash: Fake flash
- Protected area: 0 bytes
- Speed class markings: Class 10, U3, A1
- CID data:
- Manufacturer ID:
0x00
- OEM ID:
0x0000
- Product name:
0x0000000000
- Product revision:
0x00
- Serial number:
0x00000ee2
- Manufacture date: Aug 2023
- Manufacturer ID:
- Sequential read speed (MB/sec): 21.33
- Sequential write speed (MB/sec): 10.29
- Random read speed (IOPS/sec): 655.33
- Random write speed (IOPS/sec): 1.94
- Read/write cycles to first error: 49
- Read/write cycles to 0.1% failure threshold: 49
- Read/write cycles to complete failure: Not yet determined
- Total days to complete failure: Not yet determined
- Card reader used: JJC CR-UTC4AC
- Package front:
- Package back:
- Card front:
- Card back:
Discussion
Once again, this is a card I purchased — along with the smaller 16GB sibling — to see if I could find fake flash and genuine flash, and to have some knockoff cards in my results. While I didn’t expect the 16GB version to be fake flash, I did expect the 2TB to be fake. Admittedly, however, I was a little surprised to see that they were both 4GB — but perhaps I should have expected that. Surprisingly, this earned it two titles: highest price per gigabyte (at $1.469 per gigabyte), and skimpiest card (offering just 0.2% of the advertised capacity).
Performance-wise, sequential read and write scores were more than one standard deviation below average. However, when compared to the other knockoff cards in my collection, they were pretty close to average. Random read/write speeds were below average as well, even when compared to the other knockoff cards. Performance was good enough to meet the qualifications for the Class 10 mark, but not good enough for the U3 or A1 marks. I’ll throw in my standard “perhaps it would have done better under the right testing conditions” disclaimer — but I highly doubt it would have made a difference.
Endurance tests for this card are still ongoing. The card experienced a 15MB-wide data verification error during round 50; I don’t know exactly where on the card these errors took place, because the version of my program that I was running at the time didn’t log this information. Curiously, however, the sectors in question here will generally verify correctly on subsequent rounds of testing; but every few rounds, they will again fail to verify correctly, then go back to being “good” on the next round. The number of rounds between this happening seems to be variable. I’m not sure what to make of this — if this were an artifact of wear leveling, I’d expect the “bad” sectors to reappear elsewhere on the card, which they don’t seem to do. The fact that the reappear in the same place every time might be an artifact of the fact that I’m writing to the entire user area of the card. It’s still chugging along, however — it has survived 28,241 read/write cycles so far, and the total number of sectors flagged as “bad” is currently hovering just over the 1% mark.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
XrayDisk High Endurance 32GB
- Obtained from: AliExpress
- Price paid: $3.70
- Advertised size: 32GB
- Logical capacity: 31,275,876,352 bytes
- Physical capacity: 31,275,876,352 bytes
- Fake/skimpy flash: Skimpy (2.26% skimp)
- Protected area: 134,217,728 bytes
- Adjusted skimp: 1.84%
- Speed class markings: Class 10, U1, A1
- CID data:
- Manufacturer ID:
0x6f
- OEM ID:
0x0303
- Product name:
0x5344414243
(ASCII:SDABC
) - Product revision:
0x10
- Manufacturer ID:
Discussion
This is an off-brand product that came up early in my AliExpress searches, and I think the “High Endurance” part of the name may have been what inspired me to obtain the SanDisk High Endurance and Samsung PRO Endurance to have some name-brand samples to compare it to.
Performance-wise, sequential read and random read speeds were close to average. Sequential write speeds were above average, while random write speeds were below average. Compared to the other off-brand cards I tested, however, sequential speeds and random read speeds were above average, while random write speeds were below average. Performance on all three cards was good enough to qualify for the Class 10 and U1 markings that they carried, but no single card scored well enough to qualify for the A1 marking. Given that all three cards got close to the 1,500 IOPS/sec threshold for random read operations, and sample #2 got somewhat close to the 500 IOPS/sec threshold for random write operations, it’s possible that they would have performed better under proper testing conditions.
I wish measurements had been clustered closer together — but the fact that they’re not could indicate inconsistencies with how these cards were manufactured.
What really disappointed me, however, was endurance: all three of these cards only managed to go for a few read/write cycles before hitting their first error. The fact that this happened with all three cards and that the data points are so close together points to a possible quality control issue (although who am I kidding, these cards didn’t go through any quality control). On the bright side, these cards did display some ability to self-heal, as all three cards stopped displaying errors after round 136. However, endurance tests are still ongoing. As of the time of this writing:
- Sample #1 experienced a 1,258-sector wide error during round 13. I don’t know the nature of the error, because the version of the program I was using at the time didn’t log this information. It has survived 13,239 read/write cycles so far. (In the interests of full disclosure, I will say that there were more errors after round 136, but those were attributable to problems with the portions of my code that handles device disconnects/reconnects. Once those problems were fixed, the card stopped experiencing errors.)
- Sample #2 experienced a series of bit flip errors affecting 8 sectors starting in round 3; it has survived 6,891 in total so far.
- Sample #3 experienced a series of bit flip errors affecting 18 sectors during round 68, and a couple more data verification errors during rounds 761, 831, and 1,148. (Although given that the actual data read back during round 1,148 was right shifted from the expected data by exactly 4 bits, and the device experienced an error immediately afterwards that required it to be reset, I think it’s reasonable to assume that either the card or the reader missed a clock cycle while returning data.) It has survived 6,611 read/write cycles in total so far.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)
Known Issues
If I'm looking at this from a scientific point of view, there are a number of issues with the way I conducted this test. I didn't have clear goals when I started this project, and that probably contributed to these issues. Below are some issues I can think of.
Card Readers
I experimented with various card readers during the course of this experiment, trying to determine which ones would not only perform best, but also allow me to test as many cards as possible simultaneously. This resulted in using a mix of various card readers, which may have affected my results. While the obvious difference (if any) would be in performance, it's also possible that some of the other errors I encountered were due to the card reader rather than the card. (This was certainly the case with the SmartQ Single due to its tendency to randomly stop working: if it stopped working during a write operation, a certain amount of data -- usually around 1MB -- would be lost. I had to account for this in my code by rewriting the missing data when the card reader was reconnected.)
Performance Test Method
The SD Card Association's Physical Layer Specification provides a number of criteria for how speed tests are to be performed -- including block size, commands to be used, preconditioning of the card, size of write operations, size of the area to be written to, length of the test, etc. These criteria were not followed for a number of reasons -- primarily owing to the fact that USB card readers don't expose a lot of the functionality needed. I would like to develop something that could run on an FPGA and run the tests using the conditions prescribed in the specification. (I have an FPGA starter kit that I'm learning on now, but I will need a faster one at some point in the future, as I can only run the SD bus at 25MHz with the one I have. Side note: I did try to do this with an Arduino Duo as a proof of concept, but I was only able to run the SD bus at about 10KHz with it -- and the clock signal was not very stable with it.)
Endurance Test Method
The endurance test is a continuous test -- during each round, the host overwrites the entire user area of the card, as fast as conditions will allow. Once this process has finished, the host immediately proceeds to read back the entire user area of the card -- again, as fast as conditions will allow. While this is representative of some uses cases, it fails to take some other common use cases into account.
One such use case would be in a mobile phone or mobile gaming console (yes, I'm looking at you, Nintendo Switch), where the card would have a tendency to heat up and cool down according to when the user uses their device. A possible follow-up experiment would be to perform an endurance test where testing is paused (and the device is allowed to cool down) between every round or every few rounds of testing, or where the card is removed from the card reader and placed in a cold environment (such as a refrigerator or freezer) for a certain amount of time before being returned to the card reader.
Another such use case would be in a digital camera, where the ability to retain data for long periods of time is an important factor. A possible follow-up experiment would be to perform an endurance test where the card is overwritten, then placed in storage for a certain amount of time, then read back and compared to the original data written.
Host Machines Used
While I don't think it had much of an influence on my results, I did use two different machines for this experiment. Let's face it -- I'm trying to do this on the cheap, so I grabbed a couple of old laptops I had sitting around, put RAM and a hard drive back in one of them, installed Ubuntu on them, and put them to work. The first laptop I used was an MSI GE62VR-7RF that had an i7-7700HQ; the other one was a Lenovo Y580 that had an i7-3630QM. Theoretically there could have been some irregularity in the results caused by, say, differences in the USB host controller -- but at this point in time, I don't have any reason to suspect this is the case.
Ubuntu Version Used
As I mentioned above, I used two different machines for running this experiment. I set them up at different times, as I didn't expect that I was going to need a second machine. I apparently set them up with two different versions of Ubuntu: for the first machine (which was the MSI, by the way), I grabbed a Ubuntu boot stick I had laying around -- which had Ubuntu Desktop 20.04 on it -- and installed that. Since I didn't need/want the desktop environment on there, I used Ubuntu Server 22.04 for the second machine. The two are running practically the same Linux Kernel version (one is running 5.15.0-79-generic, the other is running 5.15.0-78-generic). Again, it's possible that the difference between the two introduced some irregularity into my results -- but I don't have any reason to suspect this is the case.
Heat Dissipation
These cards get hot. Really hot. How hot? This hot:
For you non-Americans, here it is in non-Freedom units:
Now...is it an issue? I don't know. I spot checked the specs for a few of the cards I'm testing, and they all listed the maximum operating temperature as 185ºF (85ºC) -- and my measurements were well below that. But does that mean that all of my cards are rated up to that temperature? Well...they probably are, but I don't know for sure.
This rig is in a small closet (probably less than 40 sq. ft.) with its own air conditioner, constantly trying to keep the room at 72ºF -- but it can only do so much. And I just don't know if that amount of heat is causing issues with the cards themselves, or if it's causing issues with the USB hub that it's attached to (which is absorbing a lot of this heat).
Conclusion
I think there's a number of conclusions I could make based on the data I've collected and what I've seen thus far::
- Capacity:
- Skimp is a problem across the industry. The only brand that was consistently not skimpy was Samsung.
- Many card brands offer cards in various capacities. When you look at prices for authentic flash, price will generally scale up as capacity goes up. (This doesn't always hold true for smaller cards -- but it almost always holds true for larger cards.) When you look at fake flash, however, the prices will generally be pretty similar -- usually within about $1 of each other -- regardless of the capacity.
- As of this writing, there's only one model of 2TB microSD card known to exist -- and that's the Kioxia Exceria Plus G2. If you see a 2TB card and it's not a Kioxia Exceria Plus G2, there's a 100% chance that it's fake.
- There are brands that will sell both fake flash and authentic flash. Usually, smaller sizes will be authentic, while larger sizes will be fake -- but there are exceptions to this.
- Performance:
- Almost all new microSD cards today support UHS-I. Under UHS-I, the maximum possible transfer rate should be 104MB/sec (although in actuality, the maximum transfer rate will be a little less than this).
- Fake flash cards usually tends to fall far short of this limit.
- Most off-brand flash cards, and many name-brand flash cards, get close to this limit -- probably as close as they can feasibly get when you factor in the time needed to issue commands, the time needed to transfer preambles/CRCs, etc. -- at least in sequential read speeds. Most cards didn't even get halfway to this mark with their sequential write speeds.
- SanDisk managed to figure out how to go over this limit -- I haven't figured out exactly how they do it, but I suspect that their trick is simply providing a faster clock signal to the card. It does, however, require both a card and a reader that support these faster transfer rates. And, while SanDisk led the way here, other brands seem to be following -- including Kingston and Samsung.
- Endurance:
- Fake flash cards (unsurprisingly) tends to fail earlier than authentic flash cards. There are isolated exceptions to this, but when it happens, it tends to be just that -- an exception to the rule.
- Name-brand flash, off-brand flash, and fake flash all tend to fail in different ways.
- Fake flash cards tends to start exhibiting bit flip errors early on. Generally, once you see your first error on a fake flash card, the number of errors (per read/write cycle) only goes up from there.
- Off-brand cards do tend to follow this same pattern, although the first error tends to happen later than it does with fake flash cards. This could be an indication that off-brand cards use higher quality flash media than fake flash cards.
- Name-brand flash doesn't necessarily last any longer than off-brand flash before experiencing its first error. However, errors with name-brand flash generally tend to be fewer and farther between. I believe this is because name-brand flash usually employs error correction and wear leveling techniques that help reduce the frequency of errors. Name-brand flash does tend to be more susceptible to address decoding errors -- and I don't know yet whether those errors could be resolved by trying to re-read the affected sector or not.
I'm still not done with this project -- I think there's still a lot of data to be gained here. So for now, I'll conclude this by leaving you with words I once heard a wise person say:
Further study is needed.
This is absolutely amazing. I came across this post from a reddit thread today. Your post is longer than most PhD dissertations and the depth plus rigor of your methodology is admirable. Thank you for this contribution.
Hello. Where I can find card-reader based on GL3230S?
Looks like there’s a company called AMALINK that makes one — you can pick them up here.
It also looks like the SanDisk Professional PRO-READER Multi Card Reader uses the GL3230S as well, according to a teardown by Camera Memory Speed.
Hey Matt! Have you made the testing scripts open-sourced at all? This is something I’d like to try testing at some point.
Yes! It’s on Github: https://github.com/mikaey/mfst