Lists all of the journal entries for the day.

Sun, 20 Feb 2011

11:01 AM - Imation drive

 After my bad experience with SSD last year, I went back to traditional hard drives.  Today, I finally got around to taking the drive apart to see if anything physical happened.  Everything looks fine so far.  Then I started searching on part numbers.  The failed Imation 32GB SSD contains Samsung 919 K9GAG08V0D chips with a JMIcron JMF602.  Searching on the Samsung chips was difficult because most references to 919 refer to a Samsung cell phone.  However, the JMicron controller turned up many hits like this one.  This article discusses performance problems with the JMF602.  It has a small cache that limits write combining and performance.  I used this drive in a server and the low cache might explain what happened.  If the drive was not aligned on a 4K boundary and it can't combine writes, it could have been doing some crazy things that wore out the beginning of the disk.  

The problem I experience might not have been Imation's fault aside from their dealings with this controller.  OCZ had to abandon the JMF602 controller for their drives because of the performance problems.  If I were to look at reviews of drives during the time period OCZ used this controller, they may also have had some reliability issues.  

As I can't determine anything about the Samsung chips, it's also possible the combination of the JMicron controller with these model Samsung parts was a perfect storm of unreliably.  Consider that a defect causing lower than expected write cycles combined with misalignment and a poor JMF602 killed the drive in 3 months.  

According to the Tom's hardware article, Intel uses another controller with 256KB cache in their drives.  That might explain the differences in benchmarks.  That article was written in 2009 so it's even quite possible all of these companies got their acts together by now.  It doesn't fix my drive. 

Imation was nice about an RMA process, but I decided not to send the drive in because it was still read only at the time.  As it was a server drive, I didn't want to take the risk someone could read the data off it. I still have the drive because I haven't come up with a good was of destroying it yet.  I'll probably just smash it to bits one of these days.

()

11:13 AM - (no subject)

Yesterday, I committed some new code to monitor the temperature on AMD K10 and K11 CPUs such as the Phenom.  I had a FreeBSD amdtemp(4) in the kernel but it had a few problems and didn't work with the sensors framework I imported from OpenBSD.

For instance, in FreeBSD the temperature can be off due to rounding with the equation to convert celcius to kelvin.  This is only .05 degrees, but when your reporting tool is accurate enough, it can be odd to see the CPU at 27.05C.  

Normally this back of the envelope calculation stuff drives me up a wall, but it's a freaking temperature sensor!  I want it to be accurate. 

()