• 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.

Would you buy a Solid State Storage HD?

What is the maximum price you'd pay for a SSS HD?

  • $0.50/GB

    Votes: 10 25.0%
  • $1.00/GB

    Votes: 10 25.0%
  • $2.00/GB

    Votes: 7 17.5%
  • $3.00/GB

    Votes: 8 20.0%
  • $5.00/GB

    Votes: 3 7.5%
  • More? Explain...

    Votes: 2 5.0%

  • Total voters
    40
  • Poll closed .

Silvermirage

Limp Gawd
Joined
Dec 14, 2005
Messages
228
At what price would you buy this technology?

Assume it's got approximately 60MB/s sustained read/write times.

(if you RAID up 2, you get 120MB/s read/write times)
 
my dad works with industrial solid state storage systems, and they get them at around 10k for a 20GB. These are industrial application drives though, not really representative i guess of mainstream uses.
 
Silvermirage said:
At what price would you buy this technology?

Assume it's got approximately 60MB/s sustained read/write times.

(if you RAID up 2, you get 120MB/s read/write times)

Only 60MB/s? No way I would purchase it unless it was significantly cheaper than your average hard drive. For the same average speed as a modern SATA drive, but with better access times, it would have to be priced around $0.25/gig for me, and come in at least 300GB sizes. As soon as the speed gets above 100MB/s, it becomes greater than the 15K SCSI drives, and I'd be willing to pay about $5.00/gig for it.
 
i certainly would pay more $/GB for a SSD disk than for a raptor, but we need to keep it in check, so $3 would be nice, I may bite for $5, depends on the performance shown.

edit: after seeing the post: What is the access time? Depending on that, somewhere between 30 cents - $3
 
with a SATA 3gb/s speed, 2-3 per GB, figuring 20-40GB total space. Just enough for windows and games.
 
It depends how many gigs you have to buy, really. Presumably they'd start out small and get bigger, so it's kind of a moot point, but Average Joe isn't going to spend $600 on it no matter how good it is per GB.

My answer: $3/GB. I anticipate waiting a long, long time.

 
a 20 gig SSD will only 100 dollars, so that is extremely reasonable.. i would pay 300 dollars for a 40 gig SSH if it had a avg sustain rate of 80MB/s and no access time
 
I'd expect it to max it's interface, and I'd pay about 2-5 dollars per gig because that's what high end scsi usually runs.
 
GLSauron said:
with a SATA 3gb/s speed, 2-3 per GB, figuring 20-40GB total space. Just enough for windows and games.

Just enough for Windows XP and games. Vista will eat up mega chunks of GB.

EDIT: Oh yeah: the poll question. I'd say $2.50/gb or so.
 
The thing is you can raid up 3 or 4 (or more) 16GB HDs and with the right controler you literally multiply the number of drives by the 60MB/s to get the sustained transfer rate...there is no dip in performance with 0 latency. @ $3-5 a gig, you get a 64GB HD @ 2.4GB/s. That is one inexpensive HD!
 
Wow, a lot of misinformation here.
No, don't even start that crap, kids. How many here have heard of Curtis? How about Texas Memory Systems? Yeah, that's what I thought. Now how many of you have actually used solid state drives? No, the iRam doesn't count. Right.

Firstly, it's not zero latency. You have bus plus controller latency. Random seek on solid state is not that spectacular either; typical 2-3ms (e.g. in SCSI range.) Bandwidth does not scale linearly due to controllers, most especially not on RAID0 or RAID5. Period.

Two Curtis Nitro!XE's in RAID1 will do about 120MB/sec on sequential read, little under 100 on write. Note sustained transfer rate; 68MB/sec, not 80MB/sec. Also note that it's access time, NOT seek time - they are different metrics.
http://www.curtisssd.com/products/drives/nitroxe/
 
AreEss said:
No, don't even start that crap, kids. How many here have heard of Curtis? How about Texas Memory Systems? Yeah, that's what I thought. Now how many of you have actually used solid state drives?
Yep, yep (home of the 1TB ram-san :D), and yep, but not on a long-term basis ;)
AreEss said:
Firstly, it's not zero latency. You have bus plus controller latency. Random seek on solid state is not that spectacular either; typical 2-3ms (e.g. in SCSI range.) Bandwidth does not scale linearly due to controllers, most especially not on RAID0 or RAID5. Period.
2-3ms how? Others' benchmarks show latencies in the tenths of a ms; for example, it's hard to see how 12000 IOPS happens unless each takes less than 0.1ms.
AreEss said:
Two Curtis Nitro!XE's in RAID1 will do about 120MB/sec on sequential read, little under 100 on write. Note sustained transfer rate; 68MB/sec, not 80MB/sec. Also note that it's access time, NOT seek time - they are different metrics.
http://www.curtisssd.com/products/drives/nitroxe/
The iRam, however generally badly done, does (marginally) better on efficiency than that (131.6 MB/s over 150 MB bus = 87%, 68/80 = 85%. Any comments on why? I would've imagined the higher access times of DDR would hurt it in this test, since it's not completely sequential reads - I can't find information on how HDTach does its test, but from the options it sounds like it reads 8MB, then skips ahead a bit, then reads another chunk, etc. So every 8MB (or about every 15th of a second, give or take) you have to do a long "seek", which (from my understanding) takes a good amount longer on ram than truly sequential access does.

In any case, it'd be interesting to see some statistics on older products like the Curtis versus the iRam et al.

 
AreEss said:
Firstly, it's not zero latency. You have bus plus controller latency. Random seek on solid state is not that spectacular either; typical 2-3ms (e.g. in SCSI range.) Bandwidth does not scale linearly due to controllers, most especially not on RAID0 or RAID5. Period.

States 60us on the website, that's probably not entirely truthful, but I would guess about .1ms is reasonable.
 
serbiaNem said:
States 60us on the website, that's probably not entirely truthful, but I would guess about .1ms is reasonable.

60us sequential optimal. Same way everyone else rates. If you're doing sequential, you still get raped by the controller and bus latency; you won't see it below a typical 500ns on PCI-X. That's command to drive; not actual data transfer. By the time it's all said and done, you're around 1ms-4ms seeks, depending on controller and bus. (Don't even ask what it was like on old VME; that made me cry.)

unhappy_mage said:
Yep, yep (home of the 1TB ram-san :D), and yep, but not on a long-term basis ;)

RAMSAN I'm not too keen on; it's just 200-pin Chipkill on a controller Meh, BTDT. The only difference is that it's a damn good controller.

unhappy_mage said:
2-3ms how? Others' benchmarks show latencies in the tenths of a ms; for example, it's hard to see how 12000 IOPS happens unless each takes less than 0.1ms.

See above; iRam most likely lies about completion, if it's using a SATA controller similar to most drives. (Which is almost certainly the case.) Also, your size matters a lot. I can break 10K IOPs if I use an itty bitty blocksize, sure. But that's not realistic, either.

unhappy_mage said:
The iRam, however generally badly done, does (marginally) better on efficiency than that (131.6 MB/s over 150 MB bus = 87%, 68/80 = 85%. Any comments on why? I would've imagined the higher access times of DDR would hurt it in this test, since it's not completely sequential reads - I can't find information on how HDTach does its test, but from the options it sounds like it reads 8MB, then skips ahead a bit, then reads another chunk, etc. So every 8MB (or about every 15th of a second, give or take) you have to do a long "seek", which (from my understanding) takes a good amount longer on ram than truly sequential access does.

First things first; iRam's not ECC 72-bit with parity. So yeah, it's going to be slightly more effecient. And significantly higher susceptability to errors. When I was working with SSDs, error rate was absolute 0% at 5 year or no dice. SSD delivered. (We also needed extremely, extremely fast seeks - this was before 10K RPM SCSI was widespread.) Also, as I've said before, I suspect the iRam lies about completion states.
Frankly, I don't trust HDTach as far as I can throw it. There is something very fishy with it, and one of these days I will be able to get it on a proper SCSI bus analyzer. (I only have one with domain verification; no command snoop capability.) Suffice to say, I don't trust numbers from it. My own benching with just dd shows significantly different numbers than HDTach on a regular basis, and I cannot find any logical reason as to why. They're also not consistently lower or higher than HDTach; just significantly different.

As far as seek goes, that's entirely controller dependent. The Curtis stuff has Hamming, ECC, etcetera, which introduces unavoidable overhead. iRam doesn't. Also, the Nitro!XE is SCSI interface controller limited; the Nitro!FC is significantly faster; >120MB/s stated.
http://www.curtisssd.com/products/drives/nitrofc/
I didn't get to play with the Nitro!FC's enough, so I can't offer any valid numbers from testing. However, the Nitro's use significantly different memory than the iRam (not even DDR, I believe SSRAM but I'm not sure) which limits them as well. There aren't any 3.5" solid state drives using DDR that I'm aware of, though ISTR someone using ZBT-SSRAM (Zero Bus Turnaround SSRAM) which I really would like to get my hands on and test.
 
AreEss said:
60us sequential optimal. Same way everyone else rates. If you're doing sequential, you still get raped by the controller and bus latency; you won't see it below a typical 500ns on PCI-X. That's command to drive; not actual data transfer. By the time it's all said and done, you're around 1ms-4ms seeks, depending on controller and bus. (Don't even ask what it was like on old VME; that made me cry.)
So 60.5 µs for command transfer time, and then 16 times that for data transfer times? That's reasonable, I guess, depending on the size of the data.
AreEss said:
See above; iRam most likely lies about completion, if it's using a SATA controller similar to most drives. (Which is almost certainly the case.) Also, your size matters a lot. I can break 10K IOPs if I use an itty bitty blocksize, sure. But that's not realistic, either.
Completion in which direction? I can believe it can lie about write completions - get the data in cache, then report done before you actually write it to storage. But how would you lie about reads? I think it might get noticed if it reported completion of reads before it had actually read anything...
AreEss said:
First things first; iRam's not ECC 72-bit with parity. So yeah, it's going to be slightly more effecient. And significantly higher susceptability to errors. When I was working with SSDs, error rate was absolute 0% at 5 year or no dice. SSD delivered. (We also needed extremely, extremely fast seeks - this was before 10K RPM SCSI was widespread.) Also, as I've said before, I suspect the iRam lies about completion states.
I was pretty disappointed as well when I discovered that the iRam didn't do parity. I don't trust non-ecc ram unless I have no other option, and magnetic storage is another option ;)
AreEss said:
Frankly, I don't trust HDTach as far as I can throw it. There is something very fishy with it, and one of these days I will be able to get it on a proper SCSI bus analyzer. (I only have one with domain verification; no command snoop capability.) Suffice to say, I don't trust numbers from it. My own benching with just dd shows significantly different numbers than HDTach on a regular basis, and I cannot find any logical reason as to why. They're also not consistently lower or higher than HDTach; just significantly different.
I don't necessarily trust HDTach to be reliable in terms of absolute numbers - even comparing it to IOmeter can get significantly different results sometimes - but it is repeatable, and indicative of performance +/- 15% or so. I think I'll play with VMware and HDTach and see if I can't figure out what it's doing.

Edit: Apparently the installer has a description of how it works. 64k data blocks are used universally; the "short" (8MB) test reads (at 64 locations) 8MB sequentially and discards the time of the first 4MB, then reports the time the second 4MB takes to transfer. The long test does 256 iterations of 16MB unchecked and then 16MB checked. Watching VMware confirms that this is in fact what it does during the STR test.

 
Back
Top