21–30 of 61 posts
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
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
Is there actually any evidence that this would improve performance significantly? Removing the translation layer means that every OS and their file systems have to do good wear leveling because otherwise you'll destroy blocks quickly.
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.
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' which is a function of the controller, which limits the total number of operations per second (IOPs). The product of the IOPs and the size of the transaction can never exceed the bandwidth of the channel. But it often is under. 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. Optimizing channel utilization requires that you figure out how many IOPs your OS/Controller can initiate and then sizing the payload to consume the max bandwidth. Large payloads and you'll push IOPs down, smaller payloads and you won't use all the bandwidth.
One of the nicer aspects of ATM was that it was designed and specified for full channel utilization with 64 byte packets which made it possible to reason about the performance and latency of an arbitrary number of streams of data moving through it.
I can remember putting ISA "hardcards" in my 286s and similar. Full circle!
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. I started talking with Intel about them early on (we used their XM-25 SSDs because it was a price point for flash that was "enough" better than spinning rust that it made sense) and they insisted on trying to sell us the same flash chips on a PCIe card for 10x the dollars, I (and many others apparently) refused to pay that. Sure if you have a 'cost is no object' data base or something but for a large internet working set where revenue differences are measured in cents per thousand transactions? Not so much. I know one company that went so far as to design and build their own PCIe Flash card. I have heard it did great stuff for them.
[1] LIM - Lotus-Intel-Microsoft spec for extended memory on IBM PC compatible machines.
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.
"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.
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
Earlier quoted context omitted.
That's just a design decision for those models. It's still PCIe, nothing is causing wasted power.
Last time I looked at the SATA PHY it seemed pretty wasteful. During every transaction the back channel was running at full speed blasting "R_OK R_OK R_OK" to the transmitting party. Not a checksum, mind you, just a bunch of magic DWORDs indicating that the drive was receiving (it would use a checksum too once the transmission was over, of course). I guess it's an easy way to keep the PLLs locked but it seemed like a…
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
Is there actually any evidence that this would improve performance significantly? Removing the translation layer means that every OS and their file systems have to do good wear leveling because otherwise you'll destroy blocks quickly.
[0] https://en.wikipedia.org/wiki/Log-structured_file_system
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'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 layers; do we want to have yet another protocol when the technology changes?