4 ms·

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 12GB

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.

carlob 12y ago
apparently it was already corrected once, but it's still chock-full of mistakes.
ChuckMcM 12y ago
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' 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.
- p1esk 12y ago
  PCIe 3.0 uses 128b/130b line encoding, not 8b/10b.
  - ChuckMcM 12y ago
    Thanks for the update. So closer to 586MBps for full bandwidth.
    - sigterm 12y ago
      PCIe2 has 5Gbps lanes. PCIe3 has 8Gbps with updated encoding.
- userbinator 12y ago
  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.
- comatose_kid 12y ago
  Didn't ATM use 53 bytes/cell?
- JohnBooty 12y ago
  > 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_500gb_review_wd5000bekt http://www.storagereview.com/western_digital_scorpio_black_5...
  - ChuckMcM 12y ago
    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/ http://www.iometer.org/ [2] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&context=pdl http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&c...
Veratyr 12y ago
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.
- hmottestad 12y ago
  2400Gbps = 3GBps going from "b" to "B" is either 8 or 10 fold. As some of the other comments have noted. SATA uses 10 bits per byte. so 2400 Gbps = 300 GBps (8 bit) or 2400 Gbps = 240 GBps (10 bit)
- wtallis 12y ago
  Since SATA uses 8b/10b encoding, the data rate in bytes/s is actually 1/10th of the raw bit rate. The same applies to earlier PCIe versions. 6Gbps SATA can transfer 600MB/s (ignoring protocol overhead). I don't really know why it's become standard to publish raw bit rates in bit/s and data rates in bytes/s with error correction taken into account but not protocol overhead, but those are the two kinds of numbers you almost always see quoted nowadays. Raw bit rates at least map pretty directly to clock speed, and I guess protocol overhead must be too variable and too complicated for most people to bother explaining.
- rosser 12y ago
  PCI-Express, SAS, SATA, and many other protocols use an 8b/10b encoding — encoding 8-bit bytes in 10-bit words. https://en.wikipedia.org/wiki/8b/10b_encoding https://en.wikipedia.org/wiki/8b/10b_encoding
- MertsA 12y ago
  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.
ghshephard 12y ago
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.

carlob 12y ago

apparently it was already corrected once, but it's still chock-full of mistakes.

ChuckMcM 12y ago

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' 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.

p1esk 12y ago
PCIe 3.0 uses 128b/130b line encoding, not 8b/10b.
- ChuckMcM 12y ago
  Thanks for the update. So closer to 586MBps for full bandwidth.
  - sigterm 12y ago
    PCIe2 has 5Gbps lanes. PCIe3 has 8Gbps with updated encoding.
userbinator 12y ago
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.
comatose_kid 12y ago
Didn't ATM use 53 bytes/cell?
JohnBooty 12y ago
> 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_500gb_review_wd5000bekt http://www.storagereview.com/western_digital_scorpio_black_5...
- ChuckMcM 12y ago
  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/ http://www.iometer.org/ [2] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&context=pdl http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&c...

Veratyr 12y ago

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.

hmottestad 12y ago
2400Gbps = 3GBps going from "b" to "B" is either 8 or 10 fold. As some of the other comments have noted. SATA uses 10 bits per byte. so 2400 Gbps = 300 GBps (8 bit) or 2400 Gbps = 240 GBps (10 bit)
wtallis 12y ago
Since SATA uses 8b/10b encoding, the data rate in bytes/s is actually 1/10th of the raw bit rate. The same applies to earlier PCIe versions. 6Gbps SATA can transfer 600MB/s (ignoring protocol overhead). I don't really know why it's become standard to publish raw bit rates in bit/s and data rates in bytes/s with error correction taken into account but not protocol overhead, but those are the two kinds of numbers you almost always see quoted nowadays. Raw bit rates at least map pretty directly to clock speed, and I guess protocol overhead must be too variable and too complicated for most people to bother explaining.
rosser 12y ago
PCI-Express, SAS, SATA, and many other protocols use an 8b/10b encoding — encoding 8-bit bytes in 10-bit words. https://en.wikipedia.org/wiki/8b/10b_encoding https://en.wikipedia.org/wiki/8b/10b_encoding
MertsA 12y ago
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.

ghshephard 12y ago

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.