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.
> 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.
To pick a 2009-era HDD review/benchmark at random that illustrates this: http://www.storagereview.com/western_digital_scorpio_black_5...
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.
[2] http://repository.cmu.edu/cgi/viewcontent.cgi?article=1136&c...
"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.
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)
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.