- 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:
| Sample # | 1 | 2 | 3 | 4 | 5 | 6 | Average |
|---|---|---|---|---|---|---|---|
| Price paid | $6.48 | $5.99* | $5.99* | $6.00* | $6.00* | $6.00* | $6.08 |
| Manufacture date | Not available | Dec 2023 | Dec 2023 | Dec 2023 | Not yet tested | Not yet tested | N/A |
| Serial number | Not available | 0x00002f01 | 0x00002033 | 0x000015d4 | Not yet tested | Not yet tested | N/A |
| Sequential read speed (MB/sec) | Not available | 85.83 | 87.43 | 91.01 | Not yet tested | Not yet tested | 88.09 |
| Sequential write speed (MB/sec) | Not available | 25.62 | 27.47 | 24.54 | Not yet tested | Not yet tested | 25.88 |
| Random read speed (IOPS/sec) | Not available | 1,603.20 | 1,610.53 | 1,414.98 | Not yet tested | Not yet tested | 1,542.90 |
| Random write speed (IOPS/sec) | Not available | 283.79 | 289.82 | 229.75 | Not yet tested | Not yet tested | 267.79 |
| Read/write cycles to first error | 1,785 | 381 | Not yet determined | Not yet determined | Not yet tested | Not yet tested | 1,083 |
| Read/write cycles to complete failure | 1,785 | Not yet determined | Not yet determined | Not yet determined | Not yet tested | Not yet tested | 1,785 |
| Total days to complete failure | 58 | Not yet determined | Not yet determined | Not yet determined | Not yet tested | Not yet tested | 58 |
| Card reader used | SmartQ Single** | JJC CR-UTC4AC | JJC CR-UTC4AC | JJC CR-UTC4AC | Not yet tested | Not yet tested | N/A |
| Package front | Not available |  | N/A | ||||
| Package back | Not available |  | N/A | ||||
| Card front |  |  |  |  | Not yet tested | Not yet tested | N/A |
| Card back |  |  |  |  | Not yet tested | Not yet tested | N/A |
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
0x3432has only appeared with cards that have their manufacturer ID set to0x00and0xfe. 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
00000has only appeared with cards that have their manufacturer ID set to0x9f. This would put it into a slightly more reputable category — which includes the Amzwn 32GB, Kodak Ultra Performance 32GB, the Kingston Industrial 8GB, and SP Elite 32GB. However, the upper four bytes of the serial number is zeroed out as well — and with the exception of the Amzwn 32GB, the other cards didn’t do this — so this might indicate that whoever manufacturer ID0x9fbelongs to, they weren’t involved in the production of this card. - Another thing we could look at is the laser etching on the back of the card — the font used, the orientation, the numbering scheme, the way in which “Made in Taiwan” is capitalized, etc. I wasn’t able to find any exact matches here, but there are several that come close: the Amzwn 32GB, the Auotkn Extreme cards, the Microdrive “Bart Simpson” 16GB, the PNY cards, the QEEDNS cards, the SanDian cards, many of the SanDisk cards, the “Sansumg” Pro Plus 2TB, the “Sony” 1024GB, and the “Xiaomi” 16GB all appear to use a similar font. Coincidentally, almost all of these (with the exception of the “Sansumg” Pro Plus 2TB) also bear some sort of “Made in Taiwan” mark — the others were manufactured elsewhere. The closest match, however, appears to be the “Xiaomi” 16GB.
I think the most interesting possibility here is the PNY cards — particularly the “Made in Taiwan” etching, which appears to have been added separately from the other etchings on the card. The font seems to be a dead-on match, the capitalization is the same, and — most notably — PNY is a brand name. They know who manufactured their cards; I’m willing to bet that whoever manufactured their cards manufactured these cards as well.
Performance scores so far have been disappointing. Sequential read scores were a little bit above average, but all other scores were slightly below average.
Sample #2-#4 are currently going through endurance testing:
- Sample #2’s first error was a four-sector wide address decoding error during round 382. It has survived 1,225 read/write cycles in total so far.
- Sample #3 has not yet reached the 2,000 read/write cycle mark. It is expected to get there sometime in October 2024.
- Sample #4 has not yet reached the 2,000 read/write cycle mark. It is currently expected to reach the 2,000 read/write cycle mark sometime in September 2024.
Samples #5 and #6 are currently in the package waiting to be tested.
August 9, 2024 (current number of read/write cycles is updated automatically every hour)