Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we learned about SSDs in 2015

zdnet.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: What we learned about SSDs in 2015

#101

Post by tracker1 »

pjc50 wrote: post #100
burntwater wrote: post #86

Earlier quoted context omitted.

While these servers can ingest video feeds, they wouldn't (typically) be saving the incoming feeds. These servers play out video over many projectors blended into a single seamless image. If you've watched the past few Olympics opening ceremonies, you most certainly saw the projections. My recent project, which was relatively small, played back a single video over 4 blended projectors. Each video frame was a 50MB unc…

Each video frame was a 50MB uncompressed TGA file, 30 times a second. Ouch! Not even a PNG?

I'd guess the time to do compression from TGA to PNG may be more than 1/30th of a second. Or at least reliably/consistently so.

Re: What we learned about SSDs in 2015

#102

Post by tracker1 »

otakucode wrote: post #94
lsc wrote: post #35

Earlier quoted context omitted.

uh, this shouldn't be voted down. Now, I don't use RAID for performance, I use raid for reliability, like parent said, and I've never actually been in a position where it would make sense, but people do use raid0 to increase performance. It happens, even if it's not nearly as common as using raid to prevent data loss.

Sure. My first purchase of SSDs were 3 80GB Intel SSDs which I put into RAID-0 and used for my primary system drive on my gaming machine. RAID-0 provides very-near 100% performance boost per drive added. Of course, it also provides the same bonuses to the likelihood of total data loss... but that was a risk I was OK with taking (and which never bit me!).

Mine was the same drive, my first SSD was the first 80GB Intel one, and just over a year of use, it started reporting itself as an 8MB drive. You never know for sure what will remain good, or be good consistently.

Re: What we learned about SSDs in 2015

#103

Post by tracker1 »

dajonker wrote: post #36
tehwalrus wrote: post #29

Earlier quoted context omitted.

> RAID isn't about connecting drives, it's about not losing data. RAID-0 is used as a way to get faster performance from spinning disk drives, as you can return parts of each read request from different (striped) drives. You also get better write performance, as your writes are split across the drives.

RAID 0 does not have any level of redundancy, so you might as well remove the 'R' in RAID and replace it by 'S' for striping or something. However, people would probably get confused if you start calling it SAID.

0 == no redundancy...

Re: What we learned about SSDs in 2015

#104

Post by _ak »

justin66 wrote: post #7
_ak wrote: post #6

At one of my previous employers, they built a massive "cloud" storage system. The underlying file system was ZFS, which was configured to put its write logs onto an SSD. With the write load on the system, the servers burnt through an SSD in about a year, i.e. most SSDs started failing after about a year. The hardware vendors knew how far you could push SSDs, and thus refused to give any warranty. All the major SSD ve…

If your SSDs were wearing out after a year, and were warrantied for a year, I'm guessing you weren't using "enterprise" SSDs?

They were enterprise models (i.e. not cheap), but they had no warranty in the first place. Every single hardware supplier simply refused to give any. I _guess_ because of the expected wear and tear.

Re: What we learned about SSDs in 2015

#105

Post by projct »

scurvy wrote: post #34
japaw wrote: post #11

"2015 was the beginning of the end for SSDs in the data center." is quit a bold statement especial when not discussing any alternative. I do not see us going back to magnetic disk, and most new storage technology are some kind of ssd...

My thoughts exactly. The article is quite inflammatory and tosses out some bold statements without really deep diving into them. My favorite: "Finally, the unpredictable latency of SSD-based arrays - often called all-flash arrays - is gaining mind share. The problem: if there are too many writes for an SSD to keep up with, reads have to wait for writes to complete - which can be many milliseconds. Reads taking as lon…

deadline seems less useful now that a bunch of edge cases were fixed in cfq (the graphs used to look way worse than this): http://blog.pgaddict.com/posts/postgresql-io-schedulers-cfq-...

Re: What we learned about SSDs in 2015

#106

Post by justin66 »

_ak wrote: post #104
justin66 wrote: post #7

Earlier quoted context omitted.

If your SSDs were wearing out after a year, and were warrantied for a year, I'm guessing you weren't using "enterprise" SSDs?

They were enterprise models (i.e. not cheap), but they had no warranty in the first place. Every single hardware supplier simply refused to give any. I _guess_ because of the expected wear and tear.

That's interesting. I don't even know how to buy these things without a warranty. Were they direct from the manufacturer?

Re: What we learned about SSDs in 2015

#107

Post by burntwater »

pjc50 wrote: post #100
burntwater wrote: post #86

Earlier quoted context omitted.

While these servers can ingest video feeds, they wouldn't (typically) be saving the incoming feeds. These servers play out video over many projectors blended into a single seamless image. If you've watched the past few Olympics opening ceremonies, you most certainly saw the projections. My recent project, which was relatively small, played back a single video over 4 blended projectors. Each video frame was a 50MB unc…

Each video frame was a 50MB uncompressed TGA file, 30 times a second. Ouch! Not even a PNG?

Uncompressed TGA is used for two reasons: Quality (this particular image was going on a screen three stories tall) and, as the other commenter mentioned, the time required to decompress images.

I'm not an expert on the exact architecture, but I'm guessing that with uncompressed TGA you just throw the bits at the GPU and they get displayed, while if you have to uncompress images that first gets handled by the CPU (?).

Re: What we learned about SSDs in 2015

#108

Post by burntwater »

im2w1l wrote: post #95
bigiain wrote: post #78

Earlier quoted context omitted.

A friend of mine does a lot of programming and installations using Dataton Watchout - where they use 4 or more 4K projectors stitched together into one big image. He's regularly got war stories about problems with the latest batch of SSDs not playing well in RAID0 causing stutters on simultaneous playback of multiple 4K video streams.

Is there an advantage compared to putting each stream on a different drive?

It's possible, and probably advantageous to a point. Eventually you'll hit bottlenecks somewhere, at which point you throw more servers at it.

Re: What we learned about SSDs in 2015

#109

Post by baruch »

wtallis wrote: post #62
fleitz wrote: post #45

Earlier quoted context omitted.

There is unpredictablilty in SSDs however, its most like whether an IOP will take 1 ns or 1 ms, instead of 10 ms, or 100 ms with an HD. The variability is an order of magnitude greater but the worst case is an is several orders of magnitude better. Quite simply no one cares that you might get 10,000 IOPS or 200,000 IOPS from an SSD when all you're going to get from a 15K drive is 500 IOPS

Best-case for a SSD is more like 10µs, and the worst-case is still tens of milliseconds. Average case and 90th percentile are the kind of measures responsible for the most important improvements. And the difference between a fast SSD and a slow SSD is pretty big: for the same workload a fast PCIe SSD can show an average latency of 208µs with 846µs standard deviation, while a low-end SATA drive shows average latency o…

Where does one find 10us reads? The NAND is usually with a Tread of 50 to 100 us so just the NAND operation itself is more than 10us.

Tprog is around 1ms and Terase can be upwards of 2ms.

All in all this means a large variability in read performance depending on what other actions are done on the SSD and how well the SSD manages the writes and erase operations in the background.

This doesn't even change with the interface (SAS/SATA/PCIe), those add their own queues, link errors and thus variability.

Then you have the differences in over provisioning that allow high OP drives to mask out better the programming and erase processes.

Re: What we learned about SSDs in 2015

#110

Post by baruch »

leonroy wrote: post #96
rsync wrote: post #15

Earlier quoted context omitted.

Just a note ... we use SSDs as write cache in ZFS at rsync.net and although you should be able to withstand a SLOG failure, we don't want to deal with it so we mirror them. My personal insight, and I think this should be a best practice, is that if you mirror something like an SLOG, you should source two entirely different SSD models - either the newest intel and the newest samsung, or perhaps previous generation int…

We ship voice recording and conferencing appliances based on Supermicro hardware, a RAID controller and 4x disks on RAID 10. We tried to mitigate the failure interval on the drives by mixing brands. Our Supermicro distributor tried to really dissuade us from using mixed batches and brands of SAS drives in our servers. Really had to dig in our heels to get them to listen. Even when you buy a NAS fully loaded like a Sy…

I can tell you that EMC and IBM both use the same drives from the same batch in an entire system of tens to hundreds of drives and while I don't know about all cases completely I did oversee a large number of systems and drives and there was never a double disk failure we had that completely took two drives. With a proper background media scan procedure you also reduce the risk of a media problem in two different drives.

Ofcourse, the SSDs we use are properly vetted for design issues and bugs in the firmware actually get fixed for us in a relatively timely manner. You get that level of service with the associated large volume.

Post reply on HN