Lab Update: The Next SSD Article, Matte vs. Glossy and Touch Screens
by Anand Lal Shimpi on August 21, 2009 4:48 PM EST- Posted in
- Storage
The SSD Relapse
I’ve been teasing everyone on Twitter with this for a while, but I’m really nearing close on the third installment of my SSD coverage. Right now I’m extensively testing TRIM on the major drives. Indilinx is the first out with official TRIM support...at least through a beta firmware. It’s currently enabled on both OCZ and Super Talent drives.
All of the text behind the next SSD article...just wait until you see the Excel sheet to go along with it
There are some limitations to TRIM. Currently the Intel Matrix Storage Manager drivers won’t pass the TRIM command through from Windows 7 to the drive’s controller. If you want TRIM to work at this point you need to use Microsoft’s drivers that come with Windows 7 (note that if you set Intel’s ICH to RAID, Windows 7 loads Intel’s MSM driver so that won’t work).
The benefit of TRIM is huge, your drive doesn’t get slower because of use, it only gets slower as you actually fill it. Intel was very careful/sneaky/shiesty to only enable TRIM on its 34nm drives. Real world performance is actually very similar between the 34nm and 50nm drives for desktop users. What makes the 34nm drive the clear buy is its support for TRIM.
I realize I haven’t said much about the 34nm G2 drives since their announcement, but Intel decided to sample after the announcement so I’ve been busy running these things through the ringer. Intel had to embarrassingly halt shipments of the drive to fix a BIOS password bug that resulted in data loss. I was actually quite surprised that Intel even let this one slip by but they’ve since put tests in place to ensure that it never happens again.
The most impressive advancements really come from the Indilinx camp. Not only has performance improved but Indilinx is actually the first to officially support the ATA8-ACS2 TRIM command. To show you the awesomeness of TRIM I've run a quick test. Here I ran my 4KB Random Write iometer script on a brand new, secure erased Super Talent drive sporting the 1711 TRIM firmware from Indilinx. I then filled the drive (simulating use over time), deleted the partition and benchmarked it again. Note that deleting a partition doesn't seem to trigger TRIM under Windows 7. You'll see that performance drops. Next, I formatted the drive (triggering TRIM) and rebenchmarked:
| SuperTalent UltraDrive GX 1711 | 4KB Random Write IOPS |
| Clean Drive | 13.1 MB/s |
| Used Drive | 6.93 MB/s |
| Used Drive After TRIM | 12.9 MB/s |
Pretty sweet huh? You'd get the same results from the Indilinx Wiper Tool, but this one happens automatically. You get nearly-new performance without doing a thing. TRIM is awesome. The firmware is available from both OCZ and Super Talent but I’d avoid it until it hits final. The Indilinx Wiper Tool is more than sufficient for your TRIMing needs for now.
The WePC Update
I’ve done some writing on a couple of things that have been on my mind lately. The first being Glossy vs. Matte displays on notebooks. It’s something I tackled last year but it’s still a worthwhile topic, especially given the attention Apple is getting. I should mention that Apple has since gone back to offering a Matte display option on its 15-inch MacBook Pros.
The other point of discussion is the future of touch screens outside of smartphones. Apple did a wonderful thing with the iPhone, but now the OEMs are struggling to figure out where touch (and multi-touch) is useful when it comes to notebooks and desktops. Help them figure it out.
Head over to WePC and check it out, leave ASUS/Intel your feedback and you may just see your opinions productized at some point :)
More Ion Cometh
Between the next SSD article and Lynnfield I'll find myself with a bit of time to tackle a look at current (and one upcoming) mini-ITX Ion platforms. My question to you is: is there anything we haven't covered with regards to Ion that you'd like to see in that article?
Facebook
Twitter
RSS
83 Comments
View All Comments
NeBlackCat - Monday, August 24, 2009 - link
I'd like to see some analysis of which is best for software development. It isn't clear to me whether compiling a large project, say the Linux kernel, would favour the small write performance of the former (which I suspect) or not.eganvarley - Monday, August 24, 2009 - link
Next thursday this Linux Weekly News article will be available for all (currently it's behind a pay-wall) : http://lwn.net/Articles/347511/">http://lwn.net/Articles/347511/In this article there is an critical enquiry about the TRIM command. It will be interesting for Anand to comment on this article. An extract :
"At the ATA protocol level, a discard request is implemented by a TRIM command sent to the device. For reasons unknown to your editor, the protocol committee designed TRIM as a non-queued command. That means that, before sending a TRIM command to the device, the block layer must first wait for all outstanding I/O operations on that device to complete; no further operations can be started until the TRIM command completes. So every TRIM operation stalls the request queue."
leexgx - Monday, August 24, 2009 - link
The way you posted is correct way , It should be doing it after any other i/o any way that is correct the trim command is sent to the drive its then up to the drive when to do the trim command when the drive is idle then it do clean up (the act of sending trim command does not mean it has to do it, it waits or that's how it should be implmented why it does not need to be qued)But I get the point that if trim command is used disk queing can not be used (or it seems that way )
eganvarley - Tuesday, August 25, 2009 - link
If you read the LWN article you will see that the TRIM command on the ATA protocol is different than the TRIM command on the SCSI protocol. It's much, much better on SCSI.techvslife - Monday, August 24, 2009 - link
I'm suprised this hasn't received discussion here, but the 1711 driver definitely causes massive data loss with Windows 7 x64 when TRIM is enabled (so using the Intel drivers, which block TRIM, will not show the problem, but the MS drivers which allow TRIM will show the bug).http://forum.crucial.com/t5/Solid-State-Drives-SSD...">http://forum.crucial.com/t5/Solid-State...-SSD-sup...
http://www.ocztechnologyforum.com/forum/showthread...">http://www.ocztechnologyforum.com/forum/showthread...
leexgx - Monday, August 24, 2009 - link
Its beta at the moment, the 1.31 firmware best to use as it has self heal (needs 15% free for it to work or 20gb free (120gb verson))techvslife - Monday, August 24, 2009 - link
It's beta at ocz (they caught the problems just as they were about to release it), but 1711 has been released as final by crucial and by supertalent, and possibly others. Therefore, make sure NOT to install 1711-based firmware if you have an SSD drive using an Indilinx barefoot controller (it might not be labeled as beta!).Visual - Monday, August 24, 2009 - link
Why exactly do SSDs slow down with use, and how does TRIM help with that?Have I understood correctly that it is only the write speeds that slow down, not the read speeds? And the reason is that the drive can write faster to completely blank "cells" but is slower when writing to already used cells because it needs to first erase them?
Then, this TRIM thing is essentially just erasing a block to prepare it for faster write in the future? But I still don't see how does TRIM support help any, as when the time comes to write some stuff, doing TRIM and then write should still take as long as without an explicit TRIM... Doing TRIM right after a delete also seems like it would not save any time, as it will make deletes slower...
Or is TRIM supposed to be used not exactly before/after a write, but scheduled in the HDD's free time, sort of like defragmentation for the old magnetic drives?
I frankly doubt that I've understood the concept, and I would appreciate some explanation in simple words - in the comments here or even in the final article, as I am sure a lot of other readers will benefit from it too.
Visual - Monday, August 24, 2009 - link
Oh sorry I forgot one more question:Can someone explain about SSDs block sizes, how to find what they are, how they relate to filesystem block sizes, RAID clusters block sizes, alignment between them, possible impact on performance and such stuff?
Sunraycer - Monday, August 24, 2009 - link
Hi Anand, I also am still interested in Ion.I am running an Intel D945GCLF2 with Atom 330 as an HTPC. I'm thinking up upgrading later in the year for Blu-Ray and HDMI. I've almost decided to go with a Core 2, but still wish the Atom could do what I want.
Right now with the D945GCLF2 I can just get by with running full screen ABC/FOX shows (VP6?) on my TV at WXGA (720p). But full screen flash (Hulu/Comcast) doesn't play. DVD playback is fine. Watching NTSC and ATSC (OTA or ClearQAM) is fine (ATSC barely works) (Hauppauge 1600). Recording NTSC is fine, but ATSC is all choppy.
An insight into how ION will handle these cases and Blu-Ray playback, beyond the great articles you've already done would be great.