[Bob]

“divide by ten to get the real throughput in gigaBYTES.”

Actually devide by 8, not 10. but agreed.

8 bits to the byte.

For storage, that's true. For serial transmission, though, each byte requires a 'start' bit and a 'stop' bit. It's long been a common practice to divide by 10 rather than 8 to convert a serial bit rate to a byte transfer rate.

[MarkL]

For storage, that's true. For serial transmission, though, each byte requires a 'start' bit and a 'stop' bit. It's long been a common practice to divide by 10 rather than 8 to convert a serial bit rate to a byte transfer rate.

And you think that high speed communications use the old style asynchronous start bit, stop bit, data link layer communications protocols? Without knowing what sort of high speed protocols they're using at the physical and data link layers, we can only guess (probably based on ATM style cells), but for the link directly to the computer, you've got IEEE 802.3, which gives you between 61 and 1497 bytes of data (don't forget the 802.2 LLC header), and the overhead is 8 bytes for the SOF delimiter, another 4 for the CRC, and another 12 for the MAC address.

Mark

[DB]

No Bob, high speed serial communications that are byte oriented commonly use HDLC (though it doesn’t have to be byte oriented) which does not have start bits and stop bits on each byte. Instead it uses zero stuffing. If there are 5 or more consecutive ones it inserts a zero in order to protect what’s called a flag byte which has 6 consecutive ones with zeros on each end. The flag bytes are what provide both frame alignment and bit alignment.

See: http://en.wikipedia.org/wiki/HDLC

So the actual overhead is dependent on the data being sent over the link. In practice I believe it typically adds about 3% to the overhead. There’s additional overhead in the IP packets due to headers (routing information) and other encapsulating packet structures like Ethernet that are commonly used in network communications.