- Obtained from: Amazon
- Advertised capacity: 64GB
- Fake/skimpy flash: No
- Protected area: 134,217,728 bytes
- Speed class markings: Class 10, U3
* This manufacturer ID/OEM ID combination is pretty well known to be associated with Lexar.
** This manufacturer ID/OEM ID combination is pretty well known to be associated with Phison.
Discussion
Oh boy, do I have a thing or two to say about these cards. So here we go.
I purchased sample #1 because I wanted to be able to have at least one UHS-II card in my results. UHS-II cards tend to be pretty expensive (comparatively speaking), which is why I initially only ordered one. It came in retail packaging, complete with a Lexar LRWM05U-7000 UHS-II card reader, and I initially planned to test it with this card reader — but fate (or Lexar?) apparently had other ideas. It almost immediately had issues, unable to make it through even its authenticity or performance tests. After a few tries, I was able to get it to complete both tests — but I found that it was much more stable when I switched it over to another reader, so I gave up on the Lexar LRWM05U-7000 and put it into a JJS CR-UTC4AC instead.
I bought the first of these cards because I wanted to be able to have at least one UHS-II card in my results. UHS-II cards tend to be pretty expensive (comparatively speaking), so I initially only ordered one. It arrived in retail packaging, which included a Lexar LRWM05U-7000 UHS-II card reader. I planned to test it using this card reader; however, it started to experience I/O errors soon after tests began. On the next attempt, I was able to get it to complete its authenticity and performance tests; but it then started experiencing I/O errors during the first round of endurance testing. Restarting the endurance test didn’t seem to help — so I decided to move it to one of the JJS CR-UTC4ACs instead.
The I/O errors stopped under the JJS reader, but then a different issue surfaced: in every round of the endurance test, there would be a handful of data verification failures. But when I looked at the data being read back and compared it to what was being written to the card, I noticed something odd. Here’s a snippet of my logs — see if you can spot the issue:
[Sat Nov 11 02:19:40 2023] 00000009e2a70200: 3e 78 78 ef e5 e9 fe cc 42 60 17 ae b7 6a 4f a6
[Sat Nov 11 02:19:40 2023] 00000009e2a70210: dd d6 24 cc 5c 53 f0 f4 16 47 f8 e5 80 04 47 df
[Sat Nov 11 02:19:40 2023] 00000009e2a70220: 51 9b cc 84 03 85 8e f0 aa c5 2a d4 72 c7 35 97
[Sat Nov 11 02:19:40 2023] 00000009e2a70230: af e9 18 b3 7d ad 77 a4 5b 31 f4 fe d1 e0 75 e2
...
[Sat Nov 11 02:19:40 2023] Actual data was:
[Sat Nov 11 02:19:40 2023] 00000009e2a70200: 3e 78 78 ef e5 e9 fe cc 42 60 17 ae b7 6a 4f a6
[Sat Nov 11 02:19:40 2023] 00000009e2a70210: 7f 45 ea b4 5c 53 f0 f4 16 47 f8 e5 80 04 47 df
[Sat Nov 11 02:19:40 2023] 00000009e2a70220: 51 9b cc 84 03 85 8e f0 aa c5 2a d4 72 c7 35 97
[Sat Nov 11 02:19:40 2023] 00000009e2a70230: af e9 18 b3 7d ad 77 a4 5b 31 f4 fe d1 e0 75 e2
...
And another mismatch that happened a couple weeks later:
[Wed Nov 29 05:10:17 2023] 000000034dafc200: db cb 0e bb 8e 05 2b b4 c0 80 c0 f9 5e ca 84 bd
[Wed Nov 29 05:10:17 2023] 000000034dafc210: 38 88 89 c0 8f 4c eb c9 43 1a df b9 fc 8a 84 df
[Wed Nov 29 05:10:17 2023] 000000034dafc220: 39 e2 88 ce fc 87 4d a9 11 e9 70 be eb 85 53 8e
[Wed Nov 29 05:10:17 2023] 000000034dafc230: 20 8a 3d c2 03 5b ee e4 cd f2 ed ac 55 1a 70 aa
...
[Wed Nov 29 05:10:17 2023] Actual data was:
[Wed Nov 29 05:10:17 2023] 000000034dafc200: db cb 0e bb 8e 05 2b b4 c0 80 c0 f9 5e ca 84 bd
[Wed Nov 29 05:10:17 2023] 000000034dafc210: f6 19 bb eb 8f 4c eb c9 43 1a df b9 fc 8a 84 df
[Wed Nov 29 05:10:17 2023] 000000034dafc220: 39 e2 88 ce fc 87 4d a9 11 e9 70 be eb 85 53 8e
[Wed Nov 29 05:10:17 2023] 000000034dafc230: 20 8a 3d c2 03 5b ee e4 cd f2 ed ac 55 1a 70 aa
...
See that? It’s always bytes 16-19 that are mismatched. Every. Single. Time.
“OK”, I thought to myself, “maybe I just got a bad card. It happens. I’ll just order another one.” So I did, and from the same Amazon seller. This one looked pretty much identical to the first one, complete with another Lexar LRWM05U-7000 card reader. This time, I decided to set that one aside, and I put it straight into one of the JJS CR-UTC4AC readers. And as soon as the endurance test started running? It started having the same issue — right down to the same four bytes being mismatched:
[Mon Nov 20 20:36:07 2023] 00000001e4b04200: 2c 7d 0a a6 e0 d2 23 8f b6 9b f3 0a 44 f8 6b a2
[Mon Nov 20 20:36:07 2023] 00000001e4b04210: 9c 4e d8 fe 8e 51 ae 43 b1 62 fe b8 aa 3d 6c 77
[Mon Nov 20 20:36:07 2023] 00000001e4b04220: 39 f8 4f 95 15 43 c2 9d 8f f6 5b 82 57 32 85 e4
[Mon Nov 20 20:36:07 2023] 00000001e4b04230: 09 79 d8 bb 17 70 11 ff 68 97 be 96 a3 d9 c5 8d
...
[Mon Nov 20 20:36:07 2023] Actual data was:
[Mon Nov 20 20:36:07 2023] 00000001e4b04200: 2c 7d 0a a6 e0 d2 23 8f b6 9b f3 0a 44 f8 6b a2
[Mon Nov 20 20:36:07 2023] 00000001e4b04210: 61 1a 0b 86 8e 51 ae 43 b1 62 fe b8 aa 3d 6c 77
[Mon Nov 20 20:36:07 2023] 00000001e4b04220: 39 f8 4f 95 15 43 c2 9d 8f f6 5b 82 57 32 85 e4
[Mon Nov 20 20:36:07 2023] 00000001e4b04230: 09 79 d8 bb 17 70 11 ff 68 97 be 96 a3 d9 c5 8d
...
This was too weird to be coincidence. I considered that maybe they were both part of the same batch, and that there was an issue with that particular batch — but the two cards have different manufacturing dates (and wildly different serial numbers). That means that either there was a manufacturing issue that went undetected for multiple batches, or there’s a design flaw with this card.
For a while, I was going to leave it at that; but at some point, I decided that I should try to have at least three samples of all the cards I’m testing — so I went back to the same Amazon seller and ordered a third one. Here’s where the story took a twist: the product packaging was identical, it included another Lexar LRWM05U-7000 card reader, the card design was the same — but the CID data indicates that it’s a completely different card! Every single field in the CID register was different from the other two samples. The manufacturer ID indicates that it was made by Phison — which has been known to make Lexar-branded cards in the past (at least, according to CameraMemorySpeed.com) — so my guess is that Lexar simply contracted out part of the production of these cards to Phison.
The package advertises read speeds of up to 150MB/sec and write speeds of up to 45MB/sec. All three samples managed to surpass 150MB/sec on sequential read speeds (putting it more than one standard deviation above average, with two of the samples scoring more than two standard deviations above average), but only sample #3 (the Phison-produced sample) managed to hit the 45MB/sec mark on sequential write speeds. Samples #1 and #2 ended up being just slightly above average in this category, while sample #3 ended up being more than one standard deviation above average.
Random I/O speeds were pretty inconsistent. When tested with the Lexar LRWM05U-7000, sample #1 got random read speeds that were more than one standard deviation above average. However, the same card, tested on the same machine with a JJS CR-UTC4AC, only managed to get about 1/4 of that. Both random read speeds and random write speeds ran the gamut from “well below average” to “more than one standard deviation above average”, depending on the card. I can’t say for sure whether the Phison-produced samples or the Lexar-produced samples were better for random read speeds, but it did seem like the Phison-produced sample was significantly better for random write speeds.
All three samples scored well enough to merit the Class 10 and U3 markings; but frankly, I would have expected better for a name-brand card that had “Professional” as part of its name — especially when there are UHS-I cards that were able to perform better.
All three samples are still undergoing endurance testing:
- Sample #1 has survived 4,783 read/write cycles so far.
- Sample #2 has survived 5,736 read/write cycles so far. (I find it curious that sample #2 has outpaced sample #1 — they’re both hooked up to the same machine, to identical card readers. However, sample #1 is averaging about 9.14 read/write cycles per day, while sample #2 is averaging about 14.85 read/write cycles per day. I don’t know why.)
- Sample #3 has survived 3,733 read/write cycles so far.
Of course, there’s one more strangeness to add to this whole thing: by round 294, the errors with sample #1 stopped completely, and did not recur until round 988. Did the card’s wear leveling algorithm simply rotate these bad sectors out into its spare space for those intervening 700-ish rounds? Or was some other factor at work here? (It’s times like these that make me wish I could see into what’s going on inside the microSD card…) Meanwhile, sample #2 is still turning up a handful of errors almost every round.
The Phison-produced sample, on the other hand, has not had quite the same issues that the Lexar-produced samples did. This sample managed to go 163 read/write cycles before its first error — a four-sector wide address decoding error. It experienced another address decoding error — this time affecting six sectors — during round 173, but has not experienced any further errors since then.
Overall, however, I wouldn’t recommend buying this card. While some of the performance metrics were good-to-impressive, it doesn’t make up for the data integrity issues that I encountered on the two Lexar-produced samples. As evidenced by the fact that I bought all three samples from the same seller and got two different cards, I think it’s fair to say that if you purchased one of these, there would be no way of knowing beforehand whether you were going to get a Lexar-produced card or a Phison-produced card. Had I used this in a digital camera and gone on a photo shoot, it’s likely that some of my pictures would have been corrupted the very first time I used the card — and any photographer will tell you that’s just not acceptable.
November 4, 2024 (current number of read/write cycles is updated automatically every hour)