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

NVMe, the fast future for SSDs

pcworld.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: NVMe, the fast future for SSDs

#51

Post by comatose_kid »

ChuckMcM wrote: post #24
ziedaniel1 wrote: post #10

The numbers in the article are all wrong. SATA's ceiling is 600 MBps (megabytes per second), not 600 Gpbs (gigabits per second). SAS goes up to 12Gbps, not 12GBps, which is actually the same thing as 1.5GBps. At least the PCIe numbers look right.

Yes they are all wrong. 6 Gbps, 600 MBps (the capital B is supposed to indicate 'Bytes' versus 'bits') the encoding is 8b/10b which is 10 bauds per 8 bit byte. PCIe 2.0 has 2.5Gbps "lanes" PCIe 3.0 has 5Gbps "lanes" they can be ganged together for additional bandwidth. (x1, x2, x4, x8, x16) it is also 8b/10b so you divide by 10 to get Bytes per second (250MBps/500MBps). Both SATA and PCIe have a 'transaction limit' w…

Didn't ATM use 53 bytes/cell?

Re: NVMe, the fast future for SSDs

#52

Post by ghshephard »

ziedaniel1 wrote: post #10

The numbers in the article are all wrong. SATA's ceiling is 600 MBps (megabytes per second), not 600 Gpbs (gigabits per second). SAS goes up to 12Gbps, not 12GBps, which is actually the same thing as 1.5GBps. At least the PCIe numbers look right.

If people would just use Mbits/sec, MBytes/sec, then the only confusion that would be left is whether they actually meant 10^6 or 2^20 when they say Mega.

Re: NVMe, the fast future for SSDs

#53

Post by pkaye »

nqzero wrote: post #19

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interface that allows us to bypass the FTL and access the underlying erase blocks

I work on SSD firmware. There is lots of restrictions and algorithms involved with using NAND and presenting a reliable storage to the end user. And many of these algorithms are tuned to the specific NAND. The FTL basically hides the ugly details.

Re: NVMe, the fast future for SSDs

#54

Post by baruch »

otterley wrote: post #30
nqzero wrote: post #19

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interface that allows us to bypass the FTL and access the underlying erase blocks

NVMe is about as simple an interface to a block device as it gets: read blocks, write blocks, and a few health/diagnostic commands. Commands and geometries that originate in spinning disks have been completely extricated. I'm not sure that I'd want the protocol to get involved in the intricacies of backing store housekeeping as you propose. Newer generations of SSDs may not even have erase blocks or translation layer…

But these details do matter when you want to achieve maximum performance and they also matter when you want to figure out what went wrong with the device when it fails.

The hiding the happens currently in the block interfaces (HDD, SSD & NVMe) definitely allow for easy integration and let things work pretty good for most cases but prevent getting full performance from the device and also obstruct diagnostics when things fail.

Re: NVMe, the fast future for SSDs

#55

Post by ChuckMcM »

yuhong wrote: post #49
ChuckMcM wrote: post #25

Earlier quoted context omitted.

But did they conform to the LIM[1] spec ? :-) They also had RAM drives you could buy. The point then as now is that increasing the "high performance" working set space of a program, increases the amount of transactional data that can be "in flight" during an operation, and that increases the overall size of the data set you can work with. I've been waiting for these boards to come down in price for about 4 years now.…

hardcards have nothing to do with LIM.

Wow, so much for relying on my memory.

http://en.wikipedia.org/wiki/Expanded_memory vs

https://books.google.com/books?id=KjwEAAAAMBAJ&pg=PA61&lpg=P...

I was thinking of the plug-in expanded memory cards rather than the plug in hard drive cards.

Re: NVMe, the fast future for SSDs

#56

Post by stellarhopper »

nqzero wrote: post #19

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interface that allows us to bypass the FTL and access the underlying erase blocks

http://lwn.net/Articles/615341/

Re: NVMe, the fast future for SSDs

#58

Post by JohnBooty »

ChuckMcM wrote: post #24
ziedaniel1 wrote: post #10

The numbers in the article are all wrong. SATA's ceiling is 600 MBps (megabytes per second), not 600 Gpbs (gigabits per second). SAS goes up to 12Gbps, not 12GBps, which is actually the same thing as 1.5GBps. At least the PCIe numbers look right.

Yes they are all wrong. 6 Gbps, 600 MBps (the capital B is supposed to indicate 'Bytes' versus 'bits') the encoding is 8b/10b which is 10 bauds per 8 bit byte. PCIe 2.0 has 2.5Gbps "lanes" PCIe 3.0 has 5Gbps "lanes" they can be ganged together for additional bandwidth. (x1, x2, x4, x8, x16) it is also 8b/10b so you divide by 10 to get Bytes per second (250MBps/500MBps). Both SATA and PCIe have a 'transaction limit' w…

  > For example a typical SATA disk control (prior to the 
  > popularity of SSDs) would do about 25,000 IOPs, and if 
  > you had 512 byte (.5K) block reads and writes, you 
  > could read and write 25,000 * .5 or 12,500K or 12 MBps 
  > (which was much lower than the theoretical bandwidth 
  > of 200MBps on 2Gbps SATA II channels.
That doesn't seem to jive with reality. What am I missing here? SATA HDDs would regularly hit 100MBps in sequential transfers.

To pick a 2009-era HDD review/benchmark at random that illustrates this: http://www.storagereview.com/western_digital_scorpio_black_5...

Re: NVMe, the fast future for SSDs

#59

Post by ChuckMcM »

JohnBooty wrote: post #58
ChuckMcM wrote: post #24

Earlier quoted context omitted.

Yes they are all wrong. 6 Gbps, 600 MBps (the capital B is supposed to indicate 'Bytes' versus 'bits') the encoding is 8b/10b which is 10 bauds per 8 bit byte. PCIe 2.0 has 2.5Gbps "lanes" PCIe 3.0 has 5Gbps "lanes" they can be ganged together for additional bandwidth. (x1, x2, x4, x8, x16) it is also 8b/10b so you divide by 10 to get Bytes per second (250MBps/500MBps). Both SATA and PCIe have a 'transaction limit' w…

> For example a typical SATA disk control (prior to the > popularity of SSDs) would do about 25,000 IOPs, and if > you had 512 byte (.5K) block reads and writes, you > could read and write 25,000 * .5 or 12,500K or 12 MBps > (which was much lower than the theoretical bandwidth > of 200MBps on 2Gbps SATA II channels. That doesn't seem to jive with reality. What am I missing here? SATA HDDs would regularly hit 100MBps…

Oh you can get faster throughput with longer reads, to get 100MBps on a 2Gbps channel you simply increase the read size until you've maxed out the bandwidth you can get.

So when characterizing a typical SATA drive you would start with 4K sequential reads and work up until your bandwidth hit either the channel bandwidth or stopped going up (which would be the disk bandwidth). Unless you ran across a reallocated sector many SATA drives could return data at a rate of 100MBps with 1MB reads. Or even smaller read sizes if you had command caching available. Random r/w was an issue of course because of head movement (burns your IOPs rate while waiting for the heads to change tracks)

You can do these experiments with iometer[1], there was a great paper out of CMU which talked about illuminating the inner workings of a drive by varying the workload[2]. Well worth playing with if you're ever trying to get the absolute most I/O out of a disk drive.

[1] http://www.iometer.org/

[2] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&c...

Re: NVMe, the fast future for SSDs

#60

Post by WeiShi »

pkaye wrote: post #53
nqzero wrote: post #19

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interface that allows us to bypass the FTL and access the underlying erase blocks

I work on SSD firmware. There is lots of restrictions and algorithms involved with using NAND and presenting a reliable storage to the end user. And many of these algorithms are tuned to the specific NAND. The FTL basically hides the ugly details.

Can you give some specific restrictions? like sequential page programming in blocks or 'LSB MSB' things?
Post reply on HN