Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Data Storage Intel Hardware

Intel Takes SATA Performance Crown With X25-E SSD 164

theraindog writes "We've already seen Intel's first X25-M solid-state drive blow the doors off the competition, and now there's a new X25-E Extreme model that's even faster. This latest drive reads at 250MB/s, writes at 170MB/s, and offers ten times the lifespan of its predecessor, all while retaining Intel's wicked-fast storage controller and crafty Native Command Queuing support. The Extreme isn't cheap, of course, but The Tech Report's in-depth review of the drive suggests that if you consider its cost in terms of performance, the X25-E actually represents good value for demanding multi-user environments."
This discussion has been archived. No new comments can be posted.

Intel Takes SATA Performance Crown With X25-E SSD

Comments Filter:
  • by Enderandrew ( 866215 ) <enderandrew AT gmail DOT com> on Monday November 24, 2008 @11:25PM (#25881127) Homepage Journal

    This just screams dedicated database storage.

  • by SuperBanana ( 662181 ) on Tuesday November 25, 2008 @12:06AM (#25881439)

    Let's see...$720 [newegg.com] for 32GB ($22/GB) versus $278 for 256GB [newegg.com] ($1/GB.)

    Keep in mind that you could buy two of those 256GB drives, mirror them, and exceed (in all likelihood) the performance of the Intel drive, and have eight times as much storage. Since reliability is pretty unproven, having them in a mirror means your ass is suitably covered.

    The absolute lowest storage density (SAS doesn't come in anything less than 36GB, and 300GB is the top-end) at $22/GB, when $4/GB is the norm for SAS drives (that's a premium of 5.5x) is a big ol' cup of Fail.

  • Re:NCQ on an SSD? (Score:2, Informative)

    by FunkyRider ( 1128099 ) on Tuesday November 25, 2008 @12:12AM (#25881487)
    Opening a bank/row to allow the memory cells to be read/written takes time, too. In RAM terms, that's called CAS Latency. This is what re-ordering helps to reduce: switching banks/rows
  • Re:NCQ on an SSD? (Score:3, Informative)

    by Rayban ( 13436 ) * on Tuesday November 25, 2008 @12:14AM (#25881495) Homepage

    NCQ gives the SSD something to do while the host is figuring out what to write or read next. Normally it's used to allow the host to fire and forget 32 commands. In this case, you queue up a bunch of stuff, then figure out what to queue next.

    SSDs are so much faster that the host is generally not keeping up with it.

  • by GigaplexNZ ( 1233886 ) on Tuesday November 25, 2008 @12:22AM (#25881567)
    Try using a RAM disk [wikipedia.org].
  • by cheater512 ( 783349 ) <nick@nickstallman.net> on Tuesday November 25, 2008 @12:33AM (#25881647) Homepage

    I often do compiles (Gentoo) on a ram disk.

    Linux desktop systems doesnt use anywhere near the amount of ram modern systems have so just make a tmpfs mount and the compiles fly. :)

  • by tfranzese ( 869766 ) on Tuesday November 25, 2008 @12:46AM (#25881763)
    Except those same drives don't exactly compare due to a poor implementation of the hardware or the write/cleaning algorithm in the JMicron controller many (all?) of those are using. The capacity and price are tempting, but the write latency especially during random accesses is beyond awful. Unless of course they were able to update the firmware on those chips to address the issue since this article was published: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=7 [anandtech.com]
  • by cheater512 ( 783349 ) <nick@nickstallman.net> on Tuesday November 25, 2008 @12:55AM (#25881827) Homepage

    It becomes a very fast cdrom - read only.

  • Re:NCQ? (Score:4, Informative)

    by Anonymous Coward on Tuesday November 25, 2008 @01:31AM (#25882019)
    From the article: "The storage controller is an Intel design that's particularly crafty, supporting not only SMART monitoring, but also Native Command Queuing (NCQ). NCQ was originally designed to compensate for the rotational latency inherent to mechanical hard drives, but here it's being used in reverse, because Intel says its SSDs are so fast that they actually encounter latency in the host system. It takes a little time (time is of course relative when you're talking about an SSD whose access latency is measured in microseconds) between when a system completes a request and the next one is issued. NCQ is used to queue up to 32 requests to keep the X25-E busy during any downtime between requests."
  • by wisty ( 1335733 ) on Tuesday November 25, 2008 @03:50AM (#25882969)

    Yes, but some legacy operating systems can only address 4G of RAM (including the graphics card). Also, some hardware may not be able to take more ram. I can't think of any machine where 64G of ram is very cheap.

  • Re:NCQ? (Score:2, Informative)

    by Anonymous Coward on Tuesday November 25, 2008 @04:20AM (#25883125)

    read here: http://techreport.com/discussions.x/15374

    Since we had her cornered, we took the opportunity to quiz Huffman about a few other matters. One of those was the interaction of Native Command Queuing and SSDs. We're familiar with NCQ as a means of dealing with the seek and rotational latency inherent in mechanical hard drives, but wondered what need there was for NCQ with SSDs. (Intel's just-announced SSDs have NCQ listed prominently among their specifications.) She said that in the case of SSDs, NCQ has the primary benefit of hiding latency in the host system. If you look at a bus trace, said Huffman, there's quite a bit of time between the completion of a command and the issuance of another one. Queuing up commands can keep the SSD more fully occupied.

  • by Godji ( 957148 ) on Tuesday November 25, 2008 @06:06AM (#25883809) Homepage
    I'm a Gentoo user too. My CPU and hard drive are decent (Core 2 Duo 3.33 Ghz, Western Digital 500 Gb RE2). I build on the root filesystem. I've never seen an I/O bound build, it's always the CPU. What are you people talking about?
  • by DXLster ( 1315409 ) on Tuesday November 25, 2008 @08:39AM (#25884601)

    "our Lotus Notes servers are almost as rough on the SAN as the DB servers, huge numbers of IOPS and almost as much storage."

    I have no idea if you fall into this category, but many, MANY Domino administrators who implement with a SAN do so in a suboptimal fashion. A Domino server should have considerable resources on local drives even if you are committed to a SAN for your primary data storage. All system NSFs should be stored on local drives, as well as your transaction log (you are using transaction logs, right?) and a dedicated indexing swap drive.

    If you're running Domino 8.0.1 or higher, you should use the non-summary item compression switch on your databases, as this can improve I/O demands by as much as 30%.

    The newest version of Domino is due this quarter, and includes the new attachment and object storage model that can also dramatically improve I/O, since it's possible to move things like email attachments into an alternative storage location. (Whether this is on the SAN or not is up to you.)

    As an IBM design partner, I've also been pushing the Domino server team to make some further improvements in I/O for future versions of Domino. Most significantly, this would include:

    1) Permitting full-text indexes to be stored in a location other than a folder adjacent to the NSF. Right now, if you're storing mail files on your SAN, you *must* store FT indexes on the SAN as well. Which is rather limiting.

    2) Pulling the view index collection object out of the NSF itself. When Domino builds a view index today, the $Collection object for that view gets stored similarly (not identically) to an attachment in the NSF itself. If you look at an NSF in the Administrator client, you can right click and select "Manage Views" to see the size impact this has on the database. More importantly, this results in dramatically more I/O to the NSF itself, and increases data fragmentation. So I've been beating the drum pretty hard to get IBM to pull that object content out of the NSF. (It was a choice many years ago to store it IN the file to keep administration simple in the days when Notes servers were brought up on NetBIOS LANs in broom closets.)

    If you'd like to see these I/O improvement implemented, contact your IBM representative and beat that drum with me. :-)

    And if you have any questions about any of this, feel free to contact me.

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"