3-Year-Old Patriot Pyro 60GB: Firmware Upgrade and Testing?

[BonzaiDuck]

This 60GB Pyro SSD had been used three years in an ISRT configuration. I don't think the SandForce played entirely well with my BIOS version and IRST version. It took me some while to discover this, and I'm not sure that there is something "wrong" per se with the SSD.

The drive may have plenty of life left in it, and I'm contemplating use of it for weekly image backups of my Sammy 840-EVO server boot-system drive. Since WHS and some utilities on the server only add up to some 20 to 25GB of space, I could run a full image backup followed by incremental updates on the Pyro. Since the server OS drive has file volatility mostly determined by registry changes, software additions and so forth, I might back it up weekly and the additional writes would be fairly inconsequential.

The idea for this is that the SSD can stay "swapped-in" and only consume a small fraction of a watt in power. The updates can be scheduled. No messing with hot-swap drives. The only better usage would be a RAID1 with another 60GB drive for the system-boot volume, and I'm not inclined to do that. RAIDing SSDs means that I'd have to look more carefully at the TRIM function, the project might not be a good idea, and I'd rather run things in AHCI mode for additional benefits otherwise not available.

WHAT IS A GOOD TESTING STRATEGY FOR AN SSD?

WHAT TESTING SOFTWARE IS AVAILABLE -- USEFUL AT LEAST FOR SANDFORCE CONTROLLERS? [Couldn't find such a utility at Patriot website.]

DO YOU HAVE ANY RECOMMENDATIONS?

HOW ADEQUATE IS A DRIVE-SCANNING BACKGROUND PROCESS WHICH PROVIDES EVERY DETAIL OF REAL-TIME "SMART" INDICATORS?

 

[BonzaiDuck]

The web-site for the utility displays the following statement:

"If you take SSD’s seriously and have already replaced conventional hard drives with SSD units, don’t forget that their life expectancy is considerably shorter than that of regular hard drives. The age of these devices is relatively short and you should be financially and organizationally ready to replace them when the time comes."

"Shorter?" I thought it was longer. What have we got ourselves into??!!

 

[Coup27]

Whoever wrote that statement seriously needs to re-word it. SSD's do have a pre-determined life span. Typically, for MLC NAND this is 3000 program/erase cycles and for TLC NAND it is 1000 program/erase cycles. Once you go beyond this number, the SSD's ability to retain your data begins to degrade. It should retain your data for 12 months if powered off, however if you hammer it long past the respective program/erase cycles this will drop considerably. Eventually if you keep writing to it, the NAND will fail and ultimately so will the SSD.

However, this needs to be placed into context. Assuming you write 10GiB per day to a 128GiB TLC based SSD with a write amplification of 3x the SSD will still last 11.7 years which demonstrates even TLC based SSD's are more than adequate for most usage cases. The only time NAND endurance becomes a real issue is write intensive workloads which would be prominently in the enterprise.

This article here does an excellent job of discussing NAND endurance and dispelling the scaremongering around it.

Incidentally HDD's do not have a pre-determined life span and can be overwritten time and time again with no specific limit which is where the comment "SSD life expectancy is shorter than HDD's" comes from. However as they are a moving mechanical part, like all moving mechanical parts it will fail eventually and often without warning. SSD lifespan can be displayed using many free programs which gives a much clearer idea of when you need to replace it.

 

[BonzaiDuck]

Thank you, Coup27.

Turning to the specifics of the Pyro 60GB I mentioned in the initiating post, there have been "interesting" developments.

Again, repeating background, this drive had functioned for 3 years in an ISRT configuration. I hold a greater subjective probability that this drive would generate occasional hiccups to the system. After a few months of troubleshooting, a decision to convert to AHCI and a single, large SSD, the hiccups are gone. This may be consistent with new information.

I ran CrystalDiskInfo for the drive in one machined, determined it was healthy. But CDI, while showing "Healthy" at "96%," provided a temperature field that was blank.

Now that I install the drive to my server system according to what I must have mentioned in first post, I have run StableBit Scanner on the the drive. It shows that 4% of the drive's useful life has been consumed. It says it's "healthy." But it notes that drive life may be significantly shortened because the temperature -- while within spec -- is high.

The summary notice about general health and temperature shows that the temperature -- and I quote -- "is above 129F . . "

The particular SMART variable labeled "Temperature" shows "262.4(degrees) F (38,0,26,0)" and states that "the drive is within manufacturer tolerances."

That temperature is about 20-25C higher than the throttling temperature for CPU silicon.

On the one hand -- I have possible causes {BIOS, IRST version, SSD} for the week-and-a-half frequency of the hiccup I mentioned in my workstation. On the other hand, it seems like the report from StableBit scanner is ridiculously high, and we've seen "bad sensors" in prior generations of CPU chips.

I'm not sure what to make of it.

 

[VirtualLarry]

The particular SMART variable labeled "Temperature" shows "262.4(degrees) F (38,0,26,0)" and states that "the drive is within manufacturer tolerances."

That temperature is about 20-25C higher than the throttling temperature for CPU silicon.

If that temp were true, you should be seeing a multitude of red sector read errors when doing a surface scan with HDTune.

 

[BonzaiDuck]

If that temp were true, you should be seeing a multitude of red sector read errors when doing a surface scan with HDTune.

Yeah. I might try and run HDTune on it soon, but the StableBit Scanner SMART data doesn't seem to show any significant errors. Everything is all "within manufacturer tolerances."

Further, the Stablebit scan shows all the sectors in the green -- no errors.

I can say I "got my money out of it" over three years. It seems to be functioning normally. I can think of other alternative backup strategies for the server OS disk, but this one doesn't add anything to the power usage . .

I'm a little peeved that the Windows server backup feature won't let me schedule incremental backups on a weekly basis, as opposed to twice daily. Without the temperature anomaly, I'd tell myself "let's wait and see how it works out." I suppose I can still tell myself the same thing . . .

 

[WT]

I've always been curious to see an MLC SSDs tolerance when used as a cache drive. This is where an SLC SSD really shines, as it was designed for numerous small writes, and altho it may not have the pure speed of the newer SSDs, my Intel 311 SLC SSD is at 97% health after 1yr 7mo. of usage.

 

[BonzaiDuck]

I've always been curious to see an MLC SSDs tolerance when used as a cache drive. This is where an SLC SSD really shines, as it was designed for numerous small writes, and altho it may not have the pure speed of the newer SSDs, my Intel 311 SLC SSD is at 97% health after 1yr 7mo. of usage.

I still suspect that the occasional "hiccups" I experienced derived from BIOS and IRST-version bugs -- possibly bugs acting together with the choice of an SSD using SandForce. IF it was for "running hot," the errors Larry inferred as certain or likely aren't occurring.

Nobody has yet faulted me for putting these low-power, low-capacity SSDs in my server for OS, swap and VSS, or OS-backup. If the Patriot suddenly fails, the fix options I have aren't that difficult -- certainly if the OS drive itself just keeps on ticking and takes a licking.

With WHS, the "server backup" feature seems to offer total inclusion of OS and data. I think I want those to be separate.