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

41–50 of 61 posts

Re: NVMe, the fast future for SSDs

#41

Post by p1esk »

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…

PCIe 3.0 uses 128b/130b line encoding, not 8b/10b.

Re: NVMe, the fast future for SSDs

#42

Post by TazeTSchnitzel »

eurleif wrote: post #40
MCRed wrote: post #36

Why not simply make an SSD Controller that has a thunderbolt port? Since Intel is building thunderbolt into its support chips now, this seems like a good way to get quick performance, plenty of bandwidth without having to come up with new standard, separate drivers, etc. Thunderbolt ports could be put on motherboards fairly easily, etc. Is there something I'm missing? Plus this would have the advantage of driving dow…

Isn't Thunderbolt just externalized PCI Express?

Thunderbolt is PCIe and DisplayPort.

Re: NVMe, the fast future for SSDs

#43

Post by ChuckMcM »

p1esk wrote: post #41
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…

PCIe 3.0 uses 128b/130b line encoding, not 8b/10b.

Thanks for the update. So closer to 586MBps for full bandwidth.

Re: NVMe, the fast future for SSDs

#44

Post by userbinator »

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…

Disk controllers since earliest ATA/IDE should be able to read or write up to 256 sectors (128KB) at a time with one command, and apparently with LBA48 it was expanded to 64K sectors (32MB!), so it's quite possible to saturate the bandwidth of the hardware, but the real bottleneck is at the filesystem level and above - only when reading/writing large amounts of data at once sequentially is this realised.

Re: NVMe, the fast future for SSDs

#46

Post by nzmsv »

jjoonathan wrote: post #17
nzmsv wrote: post #11

Earlier quoted context omitted.

The NVMe command set is pretty close to the existing SCSI spec though. In case of security the commands are the SCSI Security Protocol IN/OUT. Shameless plug: if you want to work with this stuff, check out purestorage.com/jobs

Hah, I wonder if it'll come full circle and we'll get to see AT commands sent over SCSI (all inside of NVMe). Revenge for ATAPI :P

There is already a standard for doing exactly that: passing through ATA commands wrapped in SCSI. This can come in handy when a SATA drive sits behind some bridge that speaks SCSI.

Re: NVMe, the fast future for SSDs

#47

Post by MertsA »

Veratyr wrote: post #26
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.

The author seems to be mixing these around randomly without really knowing what they mean. Another example: "While a single SATA port is limited to 600Gbps, combining four makes for 2.4GBps of bandwidth." 600Gbps * 4 = 2400Gbps = 3GBps Maybe he thinks a byte is 10 bits or something? It's also really odd that he's using Bps at all. I've never seen MBps anywhere other than this article. Usually it's Mbps and MB/s.

While the author clearly doesn't have a grasp of the bandwidth limitations of various interconnects, the size of a byte is hardware dependent. The de facto standard is 8 bits but that's just what everyone tends to pick, that's why, for instance, an octet is used to describe a byte sometimes because an octet is 8 bits.

Re: NVMe, the fast future for SSDs

#49

Post by yuhong »

ChuckMcM wrote: post #25
seatonist wrote: post #2

I can remember putting ISA "hardcards" in my 286s and similar. Full circle!

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.

Re: NVMe, the fast future for SSDs

#50

Post by mojoe »

Another cool thing about NVMe is the smaller command set -- only about 10 commands (excluding admin commands), vs the 200+ that SCSI has grown to over the years. It's fairly quick to learn.
Post reply on HN