- Obtained from: Amazon
- Advertised capacity: 32GB
- Logical capacity: Unknown
- Physical capacity: Unknown
- Fake/skimpy flash: Unknown
- 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 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | N/A |
| Serial number | Not available | 0x00002f01 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | N/A |
| Sequential read speed (MB/sec) | Not available | 85.83 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 85.83 |
| Sequential write speed (MB/sec) | Not available | 25.62 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 25.62 |
| Random read speed (IOPS/sec) | Not available | 1,603.20 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 1,603.20 |
| Random write speed (IOPS/sec) | Not available | 283.79 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 283.79 |
| Read/write cycles to first error | 1,785 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 1,785 |
| Read/write cycles to complete failure | 1,785 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 1,785 |
| Total days to complete failure | 58 | Not yet tested | Not yet tested | Not yet tested | Not yet tested | Not yet tested | 58 |
| Card reader used | SmartQ Single** | JJS CR-UTC4AC | Not yet tested | Not yet tested | 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 | Not yet tested | Not yet tested | N/A |
| Card back |  |  | Not yet tested | Not yet tested | 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.
Sample #2 is currently going through endurance testing. It has not yet reached the 2,000 read/write cycle mark.
Samples #3-#6 are all currently in the package waiting to be tested.
July 26, 2024