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

Sample #	1	2	3	Average
Manufacture date	Jun 2023	Jun 2023	Jun 2023	N/A
Serial number	0xaa000667	0xaa0004c7	0xaa00068a	N/A
Sequential read speed (MB/sec)	28.40	24.19	17.00	23.20
Sequential write speed (MB/sec)	21.35	20.13	21.53	21.00
Random read speed (IOPS/sec)	1,192.89	1,283.40	794.84	1,090.38
Random write speed (IOPS/sec)	263.39	262.16	234.16	253.24
Read/write cycles to first error	2,109	9,257	4,121	5,162
Read/write cycles to 0.1% failure threshold	2,109	Not yet determined	8,078	5,094
Read/write cycles to complete failure	2,109	Not yet determined	8,542	5,326
Total days to complete failure	47	Not yet determined	176	112
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

* 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 to NCard (?????), 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 to NCard 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,687 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)