Lexar Professional 1000x 64GB

  • Obtained from: Amazon
  • Advertised capacity: 64GB
  • Fake/skimpy flash: No
  • Protected area: 134,217,728 bytes
  • Speed class markings: Class 10, U3
Card #123Average
Price paid$13.99$12.99$11.95$12.98
Logical capacity64,087,916,544 bytes64,087,916,544 bytes64,172,851,200 bytes64,116,228,096 bytes
Physical capacity64,087,916,544 bytes64,087,916,544 bytes64,172,851,200 bytes64,116,228,096 bytes
Adjusted skimp-0.35%-0.35%-0.48%-0.39%
Manufacturer ID0x28*0x28*0x27**N/A
OEM ID0x4245 (ASCII: BE)*0x4245 (ASCII: BE)*0x5048 (ASCII: PH)**N/A
Product name0x363842484f (ASCII: 68BHO)0x363842484f (ASCII: 68BHO)0x3659444c50 (ASCII: 6YDLP)N/A
Product revision0x080x080x07N/A
Manufacture dateJan 2017Feb 2017Apr 2017N/A
Serial number0x663b0e7f0x863b1c8f0xda874480N/A
Sequential read speed (MB/sec)164.16170.52151.99162.22
Sequential write speed (MB/sec)35.4935.8949.9740.45
Random read speed (IOPS/sec)2883.531,050.902,336.092,090.17
Random write speed (IOPS/sec)125.79231.28584.21313.76
Read/write cycles to first error0016354
Read/write cycles to complete failureNot yet determinedNot yet determinedNot yet determinedNot yet determined
Total days to complete failureNot yet determinedNot yet determinedNot yet determinedNot yet determined
Card reader usedLexar LRWM05U-7000JJS CR-UTC4ACJJS CR-UTC4ACN/A
Package frontN/A
Package backN/A
Card frontN/A
Card backN/A

* 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] Expected 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: 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] Expected 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: 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] Expected 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: 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 2,587 read/write cycles so far.
  • Sample #2 has survived 3,666 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 2,104 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.

June 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 *