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 #123Average
Manufacture dateJun 2023Jun 2023Jun 2023N/A
Serial number0xaa0006670xaa0004c70xaa00068aN/A
Sequential read speed (MB/sec)28.4024.1917.0023.20
Sequential write speed (MB/sec)21.3520.1321.5321.00
Random read speed (IOPS/sec)1,192.891,283.40794.841,090.38
Random write speed (IOPS/sec)263.39262.16234.16253.24
Read/write cycles to first error2,109Not yet determinedNot yet determined2,109
Read/write cycles to complete failure2,109Not yet determinedNot yet determined2,109
Total days to complete failure47Not yet determinedNot yet determined47
Card reader usedJJS CR-UTC4ACJJS CR-UTC4ACJJS CR-UTC4ACN/A
Package frontN/A
Package backN/A
Card frontN/A
Card backN/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.

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:

RegisterValue BeforeValue After
CID6f0303434241445310aa0006670176018903034e43617264101930291200a101
CSD400e00325b59000076c67f800a4040010026ff325f5a83b92db7ff9f96400001
SCR02b58003000000000225000000000000

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.

Samples #2 and #3 have each survived for 2,054 read/write cycles. Neither of them have experienced any errors so far.

June 9, 2024

Leave a Reply

Your email address will not be published. Required fields are marked *