Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Intuitively, you would think that parallel data transmission should be faster than serial data transmission; in parallel you are transferring many bits at the same time, whereas in serial you are doing one bit at a time.

So what makes SATA interfaces faster than PATA, PCI-e devices faster than PCI, and serial ports faster than parallel?

share|improve this question
Maybe it is, but if so, howcome I see all these intel.com/content/www/us/en/chipsets/performance-chipsets/… it says multiple lanes for PCIe, and I looked up FDI on wikipedia and it said "2 independent 4-bit fixed frequency links/channels/pipes " and DMI talks of 4 links. (added- Scott's answer might partly cover that) –  barlop Jun 2 '13 at 16:51
It all boils down to clock rate. –  Daniel R Hicks Jun 2 '13 at 18:41
The existing three answers fail to mention economics, i.e. cost. It is simply cheaper to make a very-fast serial interface than a very-fast parallel interface. For transmission lines, a serial cable that uses just a few wires is cheaper than a parallel cable that will be difficult and expensive to shield. –  sawdust Jun 3 '13 at 0:27
Back in the days of DB25 and DB9 connections, you were lucky to push 115 kbit/s through serial while parallel got you 12 Mbit/s with eight parallel data pins. –  Michael Kjörling Jun 3 '13 at 8:24

7 Answers 7

You cannot formulate it this way.

Serial transmission is slower than parallel transmission given the same signal frequency. With a parallel transmission you can transfer one word per cycle (e.g. 1 byte = 8 bits) but with a serial transmission only a fraction of it (e.g. 1 bit).

The reason modern devices use serial transmission is the following:

  • You cannot increase the signal frequency for a parallel transmission without limit, because, by design, all signals from the transmitter need to arrive at the receiver at the same time. This cannot be guaranteed for high frequencies, as you cannot guarantee that the signal transit time is equal for all signal lines (think of different paths on the mainboard). The higher the frequency, the more tiny differences matter. Hence the receiver has to wait until all signal lines are settled -- obviously, waiting lowers the transfer rate.

  • Another good point (from this post) is that one needs to consider crosstalk with parallel signal lines. The higher the frequency, the more pronounced crosstalk gets and with it the higher the probability of a corrupted word and the need to retransmit it.1

So, even if you transfer less data per cycle with a serial transmission, you can go to much higher frequencies which results in a higher net transfer rate.

1 This also explains why UDMA-Cables (Parallel ATA with increased transfer speed) had twice as many wires as pins. Every second wire was grounded to reduce crosstalk.

share|improve this answer
The reciever doesn't have to wait for all lines to settle at the same time — fast parallel transmission nowdays involves measuring and then compensating for arrival delay on each wire separately. This even holds for short on-board links like CPU<->DRAM! This became possible by adopting some serial techniques like embedded clocks (e.g. 8b/10b coding) and/or training sequences. –  Beni Cherniavsky-Paskin Jun 4 '13 at 17:58
Your elaboration contradicts to your statement. You start stating that serial is slower and explain why it is faster. I think that it is the source of confusion and wonder how can it be answering. –  Val Jun 6 '13 at 12:12
@Val You're not reading the whole answer. A Bus moves more people than a car when they go the same speed - but because of the way physics works, these cars can go way faster than a bus, so it is faster to move people by using cars than buses. The same goes for data links: at the same speed, parallel cables move more data than a serial cable; however, we can push a serial cable to operate much, much faster than we can a parallel cable. If we try to speed up the parallel cable, physics causes the data be become garbage. –  Darth Android Jun 7 '13 at 19:47
@DarthAndroid: I appreciate your reply to Val. Your analogy with transportation is awesome! –  mpy Jun 8 '13 at 9:58
In fact I see upside down. It is passenger (public) transport that has higher throughtput, because you do not transport the automobile with everybody, though people prefer moving individually, in parallel automobiles and therefore, develop extensive suburbs infrastructure instead of packing people into compact, 3d cities. I see the burst of serial bits as a train. Roughly, sending a packet is expensive but it does not matter how much data you send per packet. It is therefore 1000 times cheaper to send a train of 1000 bits rather than 1000 parallel cars. –  Val Jun 9 '13 at 10:37

The problem is synchronization.

When you send in parallel you must measure all of the lines at the exact same moment, as you go faster the size of the window for that moment gets smaller and smaller, eventually it can get so small that some of the wires may still be stabilizing while others are finished before you ran out of time.

By sending in serial you no longer need to worry about all of the lines stabilizing, just one line. And it is more cost efficient to make one line stabilize 10 times faster than to add 10 lines at the same speed.

Some things like PCI Express do the best of both worlds, they do a parallel set of serial connections (the 16x port on your motherboard has 16 serial connections). By doing that each line does not need to be in perfect sync with the other lines, just as long as the controller at the other end can reorder the "packets" of data as they come in using the correct order.

The How Stuff Works page for PCI-Express does a very good explination in depth on how PCI Express in serial can be faster than PCI or PCI-X in parallel.

TL;DR Version: It is easier to make a single connection go 16 times faster than 8 connections go 2 times faster once you get to very high frequencies.

share|improve this answer
@barlop You can do parallel in Ethernet, but its not very common in consumer use, the term for it is called Channel Bonding. --correction: It has become common in consumer use, using bonding of the wireless freq. is how 802.11n can get rates up to 600 Mbit/s, they use up to 4 simultaneous serial streams. –  Scott Chamberlain Jun 2 '13 at 17:07
@barlop I gave you the the wrong term, Channel Bonding is the more broader generic term, specifically for Ethernet the correct term for what you are asking about is called Link aggregation. –  Scott Chamberlain Jun 2 '13 at 17:19
Rich Seifert wrote "Indeed, many people call IEEE 802.11 "Wireless Ethernet". While this surely flies in the face of any technology argument (it doesn't even use the same frame format as IEEE 802.3), I can live with it when speaking to people to whom the technology difference is unimportant." <-- his words. I read some years ago that he chairs and edits 802.3x and chaired Ethernet II (that's DIX Ethernet apparently, 10Mbps Ethernet) - and I read he's "an active participant in the IEEE 802.3z Gigabit Ethernet Task Force". So, quite an authority to say 802.11 isn't Ethernet. –  barlop Jun 2 '13 at 17:46
1000BASE-T Ethernet (802.3ab, "gigabit Ethernet") uses 4 wirepairs in parallel. –  MSalters Jun 2 '13 at 23:46
The economics of Ethernet are different from buses like SATA — cables are very long and expensive to replace, so you focus on upgrading electronics at the end. Early Ethernet used 1 pair of wires but standardized on 4 pairs cables anticipating future use (at that era parallel was the obvious approach to faster transmission). This turned out to be hard, due to crosstalk, but since the cables are already there it was a shame not to use them. Eventually, it became possible to do crosstalk cancellation with very complicated DSP processing->D2A-> ...cable... ->A2D->DSP processing. –  Beni Cherniavsky-Paskin Jun 4 '13 at 18:14

Parallel isn't inherently slower, but it does introduce challenges what serial communication does not.

But many of the fastest links are still parallel: The front-side bus in your computer is typically highly-parallel, and is usually among the fastest interlinks in a computer. Fiber optic connections can also be highly-parallel by carrying multiple wavelengths over a single fiber. This is expensive and therefore not typical, though. The most common form of Gigabit ethernet is actually 4 parallel channels of 250Mbit Ethernet in a single wire.

The most pronounced challenge introduced by parallelism is "crosstalk": when signal current starts or stops, it momentarily induces a small current on the wires next to it. The faster the signal, the more often this happens, and the more difficult it gets to filter out. Parallel IDE attempted to minimize this problem by doubling the amount of wires in the ribbon cable, and connecting every other wire to ground. But that solution only gets you so far. Long cables, folds and loops, and proximity to other ribbon cables all make this an unreliable solution for very high-speed signals.

But if you go with only one signal line, well then you're free to switch it as fast as your hardware will allow. It also solves subtle synchronization issues with some signals travelling faster than others.

Two wires is always theoretically twice as fast as one, but each signal line you add subtly complicates the physics, which may be better to avoid.

share|improve this answer
The FSB hasn't been a part of mainstream CPU designs since the Intel Core 2 era, AMD left it behind a few years earlier with the AMD64 design. Instead both moved the memory controller onto the CPU itself and connected everything else to the CPU with fast/narrow busses instead of the (relatively) wide/slow design of an FSB. –  Dan Neely Jun 3 '13 at 13:36
Cross-talk reduction techniques have been known for decades, but as noted in the comments to the questions they introduce additioanl costs, and some of them make the synchronization problem worse (twisted pairs with different twist-ratios have slight variations in impedance which means slight variations in transmission speeds, and ...). –  dmckee Jun 3 '13 at 18:09

Serial data transmission isn't faster than parallel. It's more convenient and so development has gone into making fast external serial interfacing between equipment units. Nobody wants to deal with ribbon cables that have 50 or more conductors.

Between chips on a circuit board, a serial protocol like I2C that needs only two wires is much easier to deal with than routing numerous parallel traces.

But there are plenty of examples inside your computer where parallelism is used to massively increase the bandwidth. For instance, words are not read one bit at a time from memory. And in fact, caches are refilled in large blocks. Raster displays are another example: parallel access to multiple memory banks to get the pixels faster, in parallel. Memory bandwith depends critically on parallelism.

This DAC device touted by Tektronix as "the world’s fastest commercially available 10-bit high speed DAC" makes heavy use of parallelism to bring in the data, which comes into the DAC over 320 lines, which are reduced to 10 through two stages of multiplexing driven by different divisions of the master 12 GHZ clock. If the world's fastest 10 bit DAC could be made using a single serial input line, then it probably would.

share|improve this answer
+1 for mentioning 50 pin ribbon cables. One of the motivations for going to SAS/SATA cables was that the wide cables were affecting the airflow inside the box. –  james Jun 3 '13 at 15:13

Parallel was the obvious way to increase speed when logic gates were slow enough that you could use similar electrical techniques for buses/cables and on-chip transmission. If you're already toggling the wire as fast as your transistor allows, so the only way to scale is using more wires.

With time, Moore's law outpaced the electromagnetic constrains so transmissions over cables, or even on-board buses, became a bottleneck compared to on-chip speeds. OTOH, the speed disparity allows sophisticated processing at the ends to use the channel more effectively.

  • Once propogation delay approaches the order of a few clocks, you start worrying about analogue effects like reflections => you need matched impedances along the way (especially tricky for connectors) and prefer point-to-point wires over multi-point buses. That's why SCSI needed termination, and that's why USB needs hubs instead of simple splitters.

  • At higher speeds you have multiple bits in flight at any given moment along the wire => you need to use pipelined protocols (which is why Intel's FSB protocols became frightfully complicated; I think packetized protocols like PCIe were a reaction to this complexity).

    Another effect is a multi-cycle penalty for switching the direction of signal flow—that's why Firewire and SATA and PCIe using dedicated wires per direction outperformed USB 2.0.

  • Induced noise, aka crosstalk, goes up with frequency. The single biggest advance in speeds came from adoption of differential signalling which dramatically reduced crosstalk (mathematically, an unbalanced charge's field goes down as R^2, but a dipole's field goes down as R^3).

    I think this is what caused the "serial is faster that parallel" impression — the jump was so large that you could go down to 1 or 2 differential pairs and still be faster than LPT or IDE cables. There was also a crosstalk win from having only one signal pair in the cable, but that's minor.

  • Wire propogation delay varies (both because wire lengths are hard to match across 90º turns, connectors etc. and because of parasitic effects from other conductors) which made synchronization an issue.

    The solution was to have tunable delays at every receiver, and tune them at startup and/or continually from the data itself. Encoding the data to avoid streaks of 0s or 1s incurs a small overhead but has electric benefits (avoids DC drift, controls spectrum) and most importantly allows dropping the clock wire(s) altogether (which isn't a big deal on top of 40 signals but is a huge deal for a serial cable to have 1 or 2 pairs instead of 2 or 3).

Note that we are throwing parallelism at the bottleneck — today's BGA chips have hundreds or thousands of pins, PCBs have more and more layers. Compare this to old 40-pin microcontrollers and 2 layer PCBs...

Most of the above techniques became indispensable for both parallel and serial transmission. It's just that the longer the wires, the more attractive it becomes to push higher rates through fewer wires.

share|improve this answer

if you look at the construction of a hard drive each bit is written and read in a serial manner to the platter(s) (one head per side of each platter) of the hard drive, they are serial devices, what the old PATA interface was doing was to convert it to parallel on the controller board of the hard drive which of course adds latency because it has to wait to read all 8 bits before it transmits the data. now with the addition of SSD drives it could make it faster to go with the parallel however now you lose compatibility with existing technology and you would need to redesign all the hardware involved.

share|improve this answer
There is so much wrong with this answer I don't even know where to begin. See the other very good answers in this very old question for what is really going on. –  psusi Apr 3 at 22:33

First of all: It isn't. Faster interface rates do nothing for an IDE drive's actual performance, which is WAY lower than the 100, 133 or 150 MB/s that current interfaces allow.

Then, of course parallelizing several data lines lets you transmit more data. But so does making the individual lines transmit faster. Doing the latter wins you real estate - in chip pin count, mainboard trace routing, connector sizes on both ends, and cable width. This is what the move to SATA is all about. Not speed. Same for the move from LPT to USB printers.

share|improve this answer
If there was an SSD with an ATA interface, said interface would easily be saturated and bottleneck performance hard. Furthermore, as others have said, the move to serial was primarily for issues of synchronization. –  Nick T Jun 3 '13 at 16:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.