Netac is a brand that came up while browsing through microSD cards on AliExpress. However, it’s not my first encounter with them: I received a Netac 8GB microSD card with one of my 3D printers. After starting this project, I looked at it a little more closely and discovered it was actually a 16GB card that had been partitioned to only use 8GB — making it the only card I’ve come across that was significantly larger than its labelled capacity. I purchased these cards partly out of curiosity to see whether they were doing this with any of their other cards as well.
Performance measurements from these cards were disappointing — especially for a “PRO” card. All performance measurements were below average:
- Sequential read: Sample #3 came in significantly lower than the other two, scoring in just the 7th percentile (as of the time of this writing). The other two samples came in at the 19th and 20th percentiles.
- Sequential write: All three scores were clustered pretty closely together, scoring between the 27th and 31st percentiles.
- Random read: Sample #3 came in significantly lower than the other two samples, scoring in just the 11th percentile. The other two samples came in at the 25th and 29th percentiles.
- Random write: Sample #3 came in a little lower than the other two samples, scoring in the 26th percentile. The other two samples came in at the 33rd and 34th percentiles.
These cards carry the U1, V10, and A1 markings. All results were good enough to qualify for the U1 and V10 markings, but none of the results were good enough to qualify for the A1 marking. However, I’ll throw in my standard disclaimer: my performance testing methods do not align with those prescribed by the SD standard; it’s possible that they would have done better had they been tested under proper conditions. But somehow…I doubt they would have.
On the endurance front:
Sample #1 was humming along without issues until round 2,110, when it randomly disconnected itself. 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 its 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 6f0303434241445310aa0006670176018903034e43617264101930291200a101CSD 400e00325b59000076c67f800a4040010026ff325f5a83b92db7ff9f96400001SCR 02b58003000000000225000000000000After the card failed, 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(where did this value come from??), 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 normal flash core) and that this portion of the flash had become corrupted — but the fact that the product ID changed toNCardreally 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 23,971 read/write cycles in total so far.
Sample #3’s first error1 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.Here’s the graph of what this card’s progression looked like:
1Sample #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.
June 18, 2025 (current number of read/write cycles is updated automatically every hour)