Gigastone Full HD Video 32GB

  • 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
Sample #123456Average
Price paid$6.48$5.99*$5.99*$6.00*$6.00*$6.00*$6.08
Manufacture dateNot availableDec 2023Dec 2023Dec 2023Not yet testedNot yet testedN/A
Serial numberNot available0x00002f010x000020330x000015d4Not yet testedNot yet testedN/A
Sequential read speed (MB/sec)Not available85.8387.4391.01Not yet testedNot yet tested88.09
Sequential write speed (MB/sec)Not available25.6227.4724.54Not yet testedNot yet tested25.88
Random read speed (IOPS/sec)Not available1,603.201,610.531,414.98Not yet testedNot yet tested1,542.90
Random write speed (IOPS/sec)Not available283.79289.82229.75Not yet testedNot yet tested267.79
Read/write cycles to first error1,785381Not yet determined2,095Not yet testedNot yet tested1,420
Read/write cycles to complete failure1,785Not yet determinedNot yet determinedNot yet determinedNot yet testedNot yet tested1,785
Total days to complete failure58Not yet determinedNot yet determinedNot yet determinedNot yet testedNot yet tested58
Card reader usedSmartQ Single**JJC CR-UTC4ACJJC CR-UTC4ACJJC CR-UTC4ACNot yet testedNot yet testedN/A
Package frontNot availableN/A
Package backNot availableN/A
Card frontNot yet testedNot yet testedN/A
Card backNot yet testedNot yet testedN/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 0x3432 has only appeared with cards that have their manufacturer ID set to 0x00 and 0xfe. 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 00000 has only appeared with cards that have their manufacturer ID set to 0x9f. 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 ID 0x9f belongs 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 2,142 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’s first error was a series of bit flips, affecting 10 sectors, during round 2,096. It has survived 3,256 read/write cycles in total so far.

Samples #5 and #6 are currently in the package waiting to be tested.

September 15, 2024 (current number of read/write cycles is updated automatically every hour)

Leave a Reply

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