• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Intel new SSD 34nm?

Status
Not open for further replies.
2 weeks....talk about keeping things hush-hush.

I'm waiting till SSDs get down to a $1 = 1GB ratio, and then I'm in.
 
Should be good, and might cause Intel to drop prices on their X25-M SSDs, or simply discontinue them. I was planning on getting another one for RAID, but given how much SSD performance increases, it might be better off just getting a single new drive with the performance of 2 older drives in RAID.
 
your computer with

single drive 1 = OS install
single drive 2 = apps and games

will run quicker than having everything on a raid array
 
XS Janus said:
I'm interested in this myself and plan to explore this kind of setup with may two VR drives next week. :)
Click to expand...

think about it.. while one drive is busy being accessed for windows functions, the other drive can be free to do game load functions and such..

having everything as a raid 0, they are no longer 2 separate drives, windows must wait for a specific windows function to be completed before being able to perform a game function, or vice versa
 
I think for SSD's they'd be faster in Raid 0, as there is really no seek time. With regular hd's you have a larger seek time, and even with NCQ there is still a slow up. My vote is on 2 ssd's in raid 0 being faster.
 
think about it.. while one drive is busy being accessed for windows functions, the other drive can be free to do game load functions and such..

having everything as a raid 0, they are no longer 2 separate drives, windows must wait for a specific windows function to be completed before being able to perform a game function, or vice versa
Click to expand...

HDD's can handle multiple IO requests per second from apps/windows/games all the same time, this typically degraded performance on traditional systems with a single HDD's due to the seek times involved. However with SSD's this is no longer an issue.

A raid 0 with both drives should benefit more than a single drive split. You will get the full benefit of the RAID during whatever activity your doing. Having 2 seperate drives will mean your potentially losing performance when just booting up/using the internet/email etc...or when your playing games that have little to no access of the windows files.
 
Toytown said:
HDD's can handle multiple IO requests per second from apps/windows/games all the same time, this typically degraded performance on traditional systems with a single HDD's due to the seek times involved. However with SSD's this is no longer an issue.

A raid 0 with both drives should benefit more than a single drive split. You will get the full benefit of the RAID during whatever activity your doing. Having 2 seperate drives will mean your potentially losing performance when just booting up/using the internet/email etc...or when your playing games that have little to no access of the windows files.
Click to expand...

what if you want to do some HD video encoding..

going from 1 drive to another is A LOT faster than keeping everythign within the same location on a RAID array
 
Unless they've fixed the write leveling issues, these drives will be just as useless as the previous generation.
 
Depends on the home use. We can make it happen in half an hour in our testing. "Never" is a very strong word.
 
mikeblas said:
Depends on the home use. We can make it happen in half an hour in our testing. "Never" is a very strong word.
Click to expand...

Does that include the X25-E? By unresponsive, do you mean the PC freezes, or do you mean the write speeds bottom out?

Also have you run the tests on other SSDs and if so, what were the results?
 
what if you want to do some HD video encoding..

going from 1 drive to another is A LOT faster than keeping everythign within the same location on a RAID array
Click to expand...

Lets say im encoding from bluray HD to a H264 encode
The max read speed i will need is around 5MB/sec and the write speed needed will be less than that.........in this case it doesnt matter if its raided or not, your not going to see any difference in speed

Lets say im encoding from Bluray HD to RAW
The max read speed i will need is around 5MB/s and i will need a lot of write speed, the raid will give higher performance and finish faster than having the source and target on different SSD's
 
fi fi fo fum, i smell trolls derailing the thread :D

bottom line, more news stories are picking up this "rumor" if we get to see a 320 GB SSD from intel at the price of a current 160GB SSD, then the raptor will be forgotten rather quickly...
 
astrallite said:
Does that include the X25-E? By unresponsive, do you mean the PC freezes, or do you mean the write speeds bottom out?
Click to expand...
First, write speeds bottom out. Then, the drive falls off the bus and fails to be recognized at POST or during subsequent enumeration of the bus.

astrallite said:
Also have you run the tests on other SSDs and if so, what were the results?
Click to expand...
Yes, with similar results.

aznx said:
Also how do you tell its not the controller crapping out?
Click to expand...
The host controller? We've tried a few different ones. The controller firmware on the drive? That's precisely the problem, according to the Intel engineers we talked with.

Megalomaniac said:
bottom line, more news stories are picking up this "rumor" if we get to see a 320 GB SSD from intel at the price of a current 160GB SSD, then the raptor will be forgotten rather quickly...
Click to expand...
Unless the performance and predictability problems have been addressed, I think you're jumping to a hasty conclusion. The drives are already at a price comparable with enterprise SAS drives, and the SAS drives haven't been forgotten because they're usable under load, while the SSD drives choke.
 
mikeblas said:
Unless the performance and predictability problems have been addressed, I think you're jumping to a hasty conclusion. The drives are already at a price comparable with enterprise SAS drives, and the SAS drives haven't been forgotten because they're usable under load, while the SSD drives choke.
Click to expand...

what kind of load??
 
mikeblas said:
First, write speeds bottom out. Then, the drive falls off the bus and fails to be recognized at POST or during subsequent enumeration of the bus.

Yes, with similar results.

The host controller? We've tried a few different ones. The controller firmware on the drive? That's precisely the problem, according to the Intel engineers we talked with.

Unless the performance and predictability problems have been addressed, I think you're jumping to a hasty conclusion. The drives are already at a price comparable with enterprise SAS drives, and the SAS drives haven't been forgotten because they're usable under load, while the SSD drives choke.
Click to expand...


Sound's like you have other problems with your test system. I have subjected my Falcon to a lot of abuse and it hasn't shown any problems at all...
 
Megalomaniac said:
fi fi fo fum, i smell trolls derailing the thread :D

bottom line, more news stories are picking up this "rumor" if we get to see a 320 GB SSD from intel at the price of a current 160GB SSD, then the raptor will be forgotten rather quickly...
Click to expand...

Back on-topic....

Yes, this would be a very well kept secret by INTEL.
Just a question...
Since this would likely at least drop the pricing of the current X25-M models...
Does Intel not announce any future date for X25-M price adjustment such as they do with processors?

A few months ago, there was a known date and a known price that the X25-M was going to.

I am guessing that is not normal, and not the case here?

Yes, a 320GB Intel SSD @ $600 would be huge. I don't think it would kill the Velociraptor and that crowd
but sales would probably grow exponentially at then less than $2/GB.

Has anyone noticed low stock or out-of-stock situations on the current X25-M models?
That would be a clue, but then the current models may not be targeted for elimination.
 
Last edited:
If its a surprise, then why announce it to the competition. But i think you are right in that prices for the X25-M will come down.

Alternatively, these new drives could be of far inferior quality and be inherently cheaper. They will still kick a raptor in the gonads, but might not be up the X25-M level.

Personal opinion, with what has been going in the SSD market in the past few weeks/months, with the new JMicro controller, the Samsung, the Indilinx controller I dont see how new SSDs could be designed to underperform the Raptor. there are some touchy areas, like the ability to upgrade firmware, but over all it seems to be shaping up nicely. Not to say that the performance has arrived at where it can be, I think it will take a while to develop, but they are on the right track.
 
Last edited:
I can't see Intel releasing a "cheap" SSD, or any other product.
It just wouldn't be worth it to them to create a support nightmare.
If a new SSD doesn't perform as reliably as the current line, I would
be stunned if it was released by them.
 
mikeblas said:
First, write speeds bottom out. Then, the drive falls off the bus and fails to be recognized at POST or during subsequent enumeration of the bus.

Yes, with similar results.

The host controller? We've tried a few different ones. The controller firmware on the drive? That's precisely the problem, according to the Intel engineers we talked with.

Unless the performance and predictability problems have been addressed, I think you're jumping to a hasty conclusion. The drives are already at a price comparable with enterprise SAS drives, and the SAS drives haven't been forgotten because they're usable under load, while the SSD drives choke.
Click to expand...

mikeblas, could you give us some background into what kind of testing you would have to do to see an SSD choke in such a manner?
 
mjz_5 said:
what kind of load??
Click to expand...
Reads aren't a problem, obviously. Sustained writes cause trouble, as they overwhelm the controller and the write-leveling algorithm. You can reproduce the problem with I/O Meter or SQLIO, or whatever tool you'd like. Just make a test with a mix of writes and reads, such that the writes will cover the whole drive's capacity. While you're reading from the device, the chipset on device's controller won't have time to prune its leveling list, and will fall behind, and end up degrading write performance and eventually bricking the drive.

extide said:
Sound's like you have other problems with your test system. I have subjected my Falcon to a lot of abuse and it hasn't shown any problems at all...
Click to expand...
The test systems are fine. I expect the problem is that your "abuse" really isn't as aggressive as you think it is.

The issues have been pretty widely discussed. One of the better write-ups is at PC Perspectives, in their Long-term performance analysis of Intel Mainstream SSDs article. The firmware update Intel provided changes the behaviour, but not by much--it's still pretty easy to brick a drive, requiring a reset. Tom's hardware also identified the unreliable write performance in their early review. Another site managed to get Intel to respond, and provides a very good explanation of the issue at hand.

Cyrilix said:
mikeblas, could you give us some background into what kind of testing you would have to do to see an SSD choke in such a manner?
Click to expand...

You could try to replicate any of the tests in the review links that I provided.

I think our common test is to run I/O Meter for an hour, doing 25% writes and 75% reads, over 64 kilobyte blocks, using sixteen threads. A similar test with SQLIo will also reveal the issue. I think we had the queue depth set to 72, but it might have been 36. The specific parameters aren't important, though: just do constant I/O with a large mix of writes and large blocks -- just like a busy database would do.
 
mikeblas said:
Reads aren't a problem, obviously. Sustained writes cause trouble, as they overwhelm the controller and the write-leveling algorithm. You can reproduce the problem with I/O Meter or SQLIO, or whatever tool you'd like. Just make a test with a mix of writes and reads, such that the writes will cover the whole drive's capacity. While you're reading from the device, the chipset on device's controller won't have time to prune its leveling list, and will fall behind, and end up degrading write performance and eventually bricking the drive.

The test systems are fine. I expect the problem is that your "abuse" really isn't as aggressive as you think it is.

The issues have been pretty widely discussed. One of the better write-ups is at PC Perspectives, in their Long-term performance analysis of Intel Mainstream SSDs article. The firmware update Intel provided changes the behaviour, but not by much--it's still pretty easy to brick a drive, requiring a reset. Tom's hardware also identified the unreliable write performance in their early review. Another site managed to get Intel to respond, and provides a very good explanation of the issue at hand.



You could try to replicate any of the tests in the review links that I provided.

I think our common test is to run I/O Meter for an hour, doing 25% writes and 75% reads, over 64 kilobyte blocks, using sixteen threads. A similar test with SQLIo will also reveal the issue. I think we had the queue depth set to 72, but it might have been 36. The specific parameters aren't important, though: just do constant I/O with a large mix of writes and large blocks -- just like a busy database would do.
Click to expand...

okay, but other than using testing software and running it all day, this problem is not likely going to happen for a home user..
 
I wonder if that's what happened to my first X-25M 160 drive. After 5 days it started getting extremely slow. Eventually the bios couldn't see the drive. I have no idea what caused it. Cause I didn't do any extreme things with it. I had to RMA that drive. My new drive same model has been working fine for weeks.

But intel should just put something into the firmware that prevents it from bricking.
 
Last edited:
mjz_5 said:
okay, but other than using testing software and running it all day, this problem is not likely going to happen for a home user..
Click to expand...
It will happen to users who do lots of sustained writes. Some "home" users do that, others don't. Most home users can't justify the cost of these drives.

Galvin said:
But intel should just put something into the firmware that prevents it from bricking.
Click to expand...
It's not that simple.
 
I thought you weren't supposed to fill up SSDs all the way anyhow...
 
You will rarely do sustained writes on a 80-160GB hard drive though, yes? Especially IOMeter runs across the entire drive. Large file creation or decompression is more CPU limited and will never really tax the memory channels.
 
I have been using my 2 120GB Vertex's on all kinds of different FW versions, hammering the living shit out of them with encoding, doing various small-write tasks, all at the same time and not one single pause, choke or stutter - they take whatever I throw at them. They have been rock solid, and I would expect the intel SSDs to be slightly better than my Vertex's..

My old Gskill TITANs? Wow, those things stuttered and slowed quite a bit on the small writes. I could get them to pause within 5 seconds, doing a massive file write test. Can't get the Vertex's to even blink to save my life - love 'em. They are the fastest of the Vertex's though, so I have "limited" experience with the whole lineup. Not to derail the thread further.....
 
astrallite said:
You will rarely do sustained writes on a 80-160GB hard drive though, yes?
Click to expand...
Huh? How do you correlate drive size to access pattern?

astrallite said:
Large file creation or decompression is more CPU limited and will never really tax the memory channels.
Click to expand...
Large file creation is I/O limited, since you have to write the file. I'm not sure how file size is relevant, though.
 
mikeblas said:
The test systems are fine. I expect the problem is that your "abuse" really isn't as aggressive as you think it is.
Click to expand...

I guess you don't quite understand how the wiper.exe app works, it basically implements a TRIM command and tells the SSD to physically erase the sectors marked as free in the file system, since "real" TRIM isnt implemented in any scenarios yet. This essnetially makes it so the drive never falls into the "used" state because (unless the drive is completely full of data) there are ALWAYS physically empty sectors available to write to.
 
mikeblas said:
Huh? How do you correlate drive size to access pattern?
Click to expand...

It's called an educated assumption. Because 1) you don't have the space you would like on a data drive 2) typical desktop user is well informed and is interested in limiting disk writes.

Large file creation is I/O limited, since you have to write the file. I'm not sure how file size is relevant, though.
Click to expand...

I imagine it's because smaller writes are less likely to cause a system hang since you aren't writing sequentially for a long period of time. How it's relevant? It's relevant if you want an intelligent conversation instead of changing the topic all the time.
 
I'm pretty sure benching IOMeter constantly is horrible for the drive. Also if you're running a database (array or what not) you should leave at least 25% free space...clearly..
 
Status
Not open for further replies.
Back
Top