What makes a communication architecture/protocol faster than others?

Question

Why is thunderbolt considered faster than other?

Apart from the inherent channel properties which affect the speed of data propagation, what else determines the speed of data transfer?

Of course more channels => parallel transfer=> more speed. Also differential signals would be much more reliable for high speed data transfer.

But how can a protocol/architecture enable faster data transfer?

I am pretty sure I am missing something fundamental here.

This is a very basic question to understand the reason for why we have so many serial communication protocols.

Answer 1

But how can a protocol/architecture enable faster data transfer?

I am unsure what you mean. A protocol change should not make much of a difference in datarate unless you're switching from a very inefficient protocol (for example, repeating every bit 4 times) to a more efficient one.

You forgot to mention Bandwidth. An oldfashioned serial connection is quite slow (up to 115200 bits/second) by today's standards as it has a very low bandwith due to the electronics, wires and connectors that are used.

Thunderbolt is much faster not only because it uses more connections in parallel but those connections need to have a high bandwidth. You cannot use the same type of wire that would suffice for the 115200 bits/second serial connection. For Thunderbolt you need high bandwidth (a couple of GHz) capable wire that has shielding even though differential signalling is used. Obviously high speed electronics are needed as well. Also the signal lines need to be properly terminated with the correct impedance at each end.

All that isn't needed for a slow serial connection.

I am sure I can make a slow serial connection work over a couple of meters distance using almost any piece of wire that you give me. To make a working Thunderbolt connection over a couple of meters distance you need a suitable Thunderbolt compatible cable, little else will work.

Answer 2

That depends on your definition of "faster" which in turn depends on what you're doing with the communication channel.

Simple case: unidirectional

The "display" part of HDMI (let's not mention the embedded extras like I2C etc) is a unidirectional source synchronous serial link using multiple differential channels. This is the simplest as it is unidirectional. The sender uses specified protocol to pack data into frames and transmits them, the receiver processes it, but does not reply. There are no ACKnowledgements, no retransmission in case of error, etc. It is purely a stream.

This is similar to say, RS-232 Serial, SPDIF, UDP over Ethernet...

In this case, "speed" is purely throughput in bits per second. That's determined by your physical channel properties (bandwidth, noise, etc) as per Shannon's theorem which gives an upper bound for the capacity of a channel in bits/second. This is easy to grasp intuitively: more bandwidth means more capacity, and more noise means less capacity. In a real design, bit error rate is also a design parameter. Shannon's capacity is an upper bound, assuming a perfect error correction code is available. In practice, actual capacity will be lower, and the less errors you want, the more redundancy and "safety margins" you will need, which also reduces throughput.

How much of the available capacity is actually utilized depends a lot on the channel coding and protocol used. For example, using an error-correction code allows to increase throughput while keeping the bit error rate under control, up to a point. In some cases, like SPDIF an error-detection code is enough, and the receiver "hides" errors by interpolating over the corrupted sample. In other cases, like RS-232 serial, the bit error rate is assumed to be "low enough" and error handling is not implemented.

The protocol itself will also influence throughput, via packet headers which are overhead and consume bandwidth for example.

Harder case: Bidirectional

USB, Thunderbold, PCIexpress, TCP/IP aren't simple streams, they are bidirectional and both sender and receiver talk to each other. They may acknowledge that packets are properly received, request retransmission in case of error, etc.

This makes latency quite important. If packets must be re-transmitted in case of error, then the sender must keep in its own RAM all the data that has been transmitted but not acknowledged yet by the receiver, in case the receiver requests a re-transmission. Thus we have a design compromise between RAM size (expensive), latency (imposed by transmission distance, number of hops/hubs, packet size, etc) and throughput. Since a packet can only be ACK'ed once it is completely received and error-checked, smaller packets may be an advantage and offer lower latency, but there is more overhead for headers, etc.

For example, a LPC4330 microcontroller with 100BaseT ethernet and 64kB dedicated to packet buffer will happily saturate an ethernet connection with UDP packets. But 64kB is only 6.5 milliseconds worth of buffering at full throughput, so if you want to use TCP to a destination with a 30ms ping, it won't work. You'll have to lower throughput until you have enough buffers to keep all non-ACKed packets in case they need retransmission.

So there are lots of compromises at the protocol level to optimize performance for a particular use case, which is why there is no one-size-fits-all protocol.

Real Time

Sometimes "faster" means "lowest latency" and throughput is only important as it reduces the time required to transmit N bytes of data, but the link won't be used at full capacity. As an example, SPI has very low latency (just the time to transmit a few bytes) but USB has quite high latency because "real-time" isochronous or interrupt transfers only occur on each µframe. Also USB has a lot more software and protocol overhead. So if you want to control something in real-time and you don't want extra phase lag in your control loop, SPI would be a much better choice.

Final boss: USB mass storage

Most of the time you're not just transmitting data for the sake of it, but in order to actually do something, for example read a file from a USB stick.

In this case protocol is extremely important for performance. Consider a transaction between host and device like:

Host - "Device, send sector 123" Device - ACK ...device fetches data... Device - sends data Host - ACK Host - "Device, send sector 124"

Each exchange takes time (latency) so a protocol that can do more things in less exchanges will be "faster" although it transmits data at the same speed, because it will waste less time waiting, and more time transmitting. Let's upgrade this protocol:

Host - "Device, send sectors 1 to 100000"

In this case, the device will try to push data through the channel for the entire read range at maximum throughput, without having to wait for a new command after each sector.

An even more efficient protocol would use Command Queuing (like SATA NCQ) to reduce latency even more.

This explains the difference in benchmarks between random reads and sequential reads for example.

Answer 3

This question is as wide as the entire branch of electrical engineering - communication. In short, a communication link is faster if it uses faster bit switching, and if it is wider. No tricks here. The trick is how a communication protocol achieves faster data rates over individual lines, and how it combines the individual lines into parallel words.

Faster data rates of copper connects are achieved by using differential signaling, smaller signal swing amplitudes, and redundant data and clock encoding.

Differential signaling is a no-brainer, but reducing amplitudes down to 50-100mV requires additional effort to make the signal decodable on receiver end. To make the signal decodable with simple single-threshold receiver, people drive signal edges at higher amplitude, and "de-emhasize" signal plateaus. Or use more sophisticated multi-level data encoding. Data are encoded in such a way that transmission of long 0000000... or 1111111... does not cause the signal to keep the line in one physical state for long time, otherwise the transmission line will be charged in one direction, and it will be difficult to switch it back to the background level. So the data are encoded in the way that the physical levels are constantly switching even if the data pattern doesn't change. Whichever protocol does this equalization better, it will achieve higher data rates.

Another feature of modern protocols is that they "embed" the clock within data. And the receiver end uses so-called CDR - clock-data-recovery, to extract right data from the signal. Signals in modern protocol look like just a white noise, and special circuitry and algorithms are used to get correct data out of all this mess.

Yet another feature for a good fast communication protocol is its ability to tune their receiver and transmitters to accommodate electrical channel properties. At 20 GHz+ signal rates all copper wires surrounded by dielectric insulation do attenuate the signal, and with different degree depending on frequency component. Modern serial protocols employ "linear equalization" of channels they are connected to. They use a programmable filter that amplifies higher frequencies relative of low ones. Since in many cases the channel can be anything (like a USB cable, or a different memory module, or properties of PCB trace change with board temperature), modern protocols adjust the shape of their input filter dynamically. The process of adjustment is called "link training". Modern protocols perform link training on every exit from low power state (which is another important chapter in communication protocol). Links can do power transitions on a millisecond basis and faster. Every time the link comes out of idle state, the transmitters on both ends of lines sent special synchronization and training sequences before the receiver CDR locks into stable and decodable patterns. Whichever protocol architecture does this process faster, it will have less overhead and faster overall.

Yet another areas is how a protocol merge individual (and nearly asynchronous) lanes into a wider bus, how to auto-correct individual accidental errors, how to recover from bigger errors. Whoever can do this faster and smoother has a "faster bus". Yet another modern feature is to automatically/dynamically switch number of used lanes and their base rate depending of actual data transfer demand, as PCIe 4+ does.

So, as one can see, there is quite a bit more in bus architectures than just be wider and use differential lines.