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

81–90 of 111 posts

Re: What we learned about SSDs in 2015

#81

Post by wtallis »

kijiki wrote: post #74
lsc wrote: post #65

Earlier quoted context omitted.

>M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will reach the limits on capacity, heat, or link speed first, but all of those limits are clearly much closer than for add-in cards. No argument on m.2 - it's a consumer grade technology. No doubt, someone in the "cloud" space…

You're probably tired of hearing this from me, but if you distribute the storage, you can evacuate all the VMs off a host, down it, do whatever, bring it back up, and then unevacuate.

And if uptime is that important, you can just buy a server that supports PCIe hotswap.

Re: What we learned about SSDs in 2015

#82

Post by lsc »

wtallis wrote: post #81
kijiki wrote: post #74

Earlier quoted context omitted.

You're probably tired of hearing this from me, but if you distribute the storage, you can evacuate all the VMs off a host, down it, do whatever, bring it back up, and then unevacuate.

And if uptime is that important, you can just buy a server that supports PCIe hotswap.

can you point me at a chassis designed for that?

Re: What we learned about SSDs in 2015

#83

Post by lsc »

kijiki wrote: post #74
lsc wrote: post #65

Earlier quoted context omitted.

>M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will reach the limits on capacity, heat, or link speed first, but all of those limits are clearly much closer than for add-in cards. No argument on m.2 - it's a consumer grade technology. No doubt, someone in the "cloud" space…

You're probably tired of hearing this from me, but if you distribute the storage, you can evacuate all the VMs off a host, down it, do whatever, bring it back up, and then unevacuate.

> You're probably tired of hearing this from me, but if you distribute the storage, you can evacuate all the VMs off a host, down it, do whatever, bring it back up, and then unevacuate.

Yes. The same conversation is happening right now in the living room, because security has forced three reboots in the last year, after having several years where simply by being xen and pv and using pvgrub (rather than loading a user kernel from the dom0) we haven't been vulnerable to the known privilege escalations. This is a lot more labor (and customer pain) when you can't move people.

No progress on that front yet, though.

Re: What we learned about SSDs in 2015

#84

Post by simoncion »

Dylan16807 wrote: post #64
TeMPOraL wrote: post #41

Earlier quoted context omitted.

Ever tried to play a modern computer game? You never have enough RAM for stuff; a lot of content gets dumped onto hard drive sooner or later (virtual memory), or is be streamed from the drive in the first place. Having faster access helps tremendously. From my observation, actually most personal and business use machines are IO-bound - it often takes just the web browser itself - with webdevs pumping out sites filled…

I don't think I've touched a game on PC where you can't fit all the levels into RAM, let alone just the current level. Sometimes you can't fit music and videos into ram, but you can stream that off the slowest clunker in the world. A game that preloads assets will do just fine on a bad drive with a moderate amount of RAM. Loading time might be higher, but the ingame experience shouldn't be affected. As far as swappin…

> I don't think I've touched a game on PC where you can't fit all the levels into RAM, let alone just the current level.

I know, right?! I would rather like it if more game devs could get the time required to detect that they're running on a machine with 16+GB of RAM and -in the background, with low CPU and IO priority- decode and load all of the game into RAM, rather than just the selected level + incidental data. :)

Re: What we learned about SSDs in 2015

#85

Post by mirimir »

bigiain wrote: post #79
dajonker wrote: post #36

Earlier quoted context omitted.

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.

Complaining about industry-standard terminology like this is mostly a waste of time. The sort of people who need to know that but don't aren't going to learn it from a post on HN, and the sort of people who'll read it on HN mostly don't need to be told.

Sad but true. I gather that RAID0 has been the default for notebooks with two drives. And for the first 1TB MyBooks.

Re: What we learned about SSDs in 2015

#86

Post by burntwater »

ersii wrote: post #66
burntwater wrote: post #54

Earlier quoted context omitted.

High-end video servers used in the entertainment industry typically use RAID 0. My last project, for example, used 10 250GB SSDs in RAID 0.

What kind of video servers are you talking about? For ingesting from a feed/camera in? Streaming out video? Curious.

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 uncompressed TGA file, 30 times a second. On a more complex show, you could be trying to play back multiple video streams simultaneously.

D3 - http://www.d3technologies.com/ and Pandora - http://www.coolux.de/products/pandoras-box-server/

are two of the big players in the industry.

Re: What we learned about SSDs in 2015

#87

Post by something2324 »

velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

This is a bit of a question from my lack of understanding of disk IO:

But would this in practice play well with the CPU prefetcher? If you're crunching sequential data can you expect the data in the L1 cache after the initial stall?

Re: What we learned about SSDs in 2015

#88

Post by tim333 »

Hoff wrote: post #17

FWIW, the top-end HPE SSD models are rated for up to 25 writes of the entire SSD drive, per day, for five years. The entry-level SSDs are rated for ~two whole-drive writes per week. Wear gage, et al. http://www8.hp.com/h20195/v2/GetPDF%2Easpx%2F4AA4%2D7186ENW%...

Also maybe of interest, the Techreport The SSD Endurance Experiment. Their assorted drives lasted about 2,000 - 10,000 whole disk writes.

http://techreport.com/review/27909/the-ssd-endurance-experim...

Re: What we learned about SSDs in 2015

#89

Post by dragontamer »

something2324 wrote: post #87
velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

This is a bit of a question from my lack of understanding of disk IO: But would this in practice play well with the CPU prefetcher? If you're crunching sequential data can you expect the data in the L1 cache after the initial stall?

SSDs are still grossly slower than RAM. The fastest SSD I know of is the Intel 750, which is like ~2.0 GigaBYTES/second (or for what is more typical for storage benchmarks: about 16Gbps or so over PCIe x4).

Main DDR3 RAM is something like 32GigaBYTES per second, and L1 cache is even further.

What I think the poster was talking about, is moving from disk-based databases to SSD-based databases. SSDs are much faster than hard drives.

L1 Cache, L2 Cache, L3 Cache, and main memory are all orders of magnitude faster than even the fastest SSDs today. Thinking about the "CPU prefetcher" when we're talking about SSDs or Hard Drives is almost irrelevant due to the magnitudes of speed difference.

Re: What we learned about SSDs in 2015

#90

Post by rodionos »

>log-structured I/O management built into SSDs is seriously sub-optimal for databases and apps that use log-structured I/O as well

This assert piqued my interest given that my hands-on experience with HBase speaks to the contrary. The paper by SanDisk they refer to https://www.usenix.org/system/files/conference/inflow14/infl... seems to suggest that most of the issues are related to sub-optimal degragmentation by the disk driver itself. More specifically, the fact that some of the defragmentation is unnecessary. Hardly a reason to blame the databases and can be addressed down the road. After all, GC in Java is still an evolving subject.

Post reply on HN