4 ms·

" serial communication is almost always faster than parallel communication." Its a bit more complex than that. The PC serial port's top speed from the PC->prin

" serial communication is almost always faster than parallel communication." Its a bit more complex than that. The PC serial port's top speed from the PC->printer/etc was significantly faster than serial at the time. Its only in the reverse direction that there were problems (note comment above about using the control lines for device->PC). And that is by design, the ISA/PCI/RAM/etc buses were parallel, and despite many of them becoming "serial" are still technically parallel (ex: PCIe) because its far easier to gang a bunch of serial data lines together and deal with said synchronization (which is frequently fixed by the hw design/trace length/etc) than attempt ever higher serial frequencies. And that is fundamentally the problem with trying to use serial as a high speed peripheral interconnect (see HDMI vs displayport for an nice example of hitting walls). Eventually one runs out of bandwidth and the solution ends up being ganging a pile of them together into a... parallel bus. Its why thunderbolt will perpetually be a loser when it comes to GPU attach/etc. A serdes at N Ghz+PAM can just be put on a motherboard x16, and each line is synchronized at a higher level instead of each bit. Ex: PCIe 6. Same with RAM buses, the latency and bandwidth advantages have basically kept them parallel buses (using per line serdes kinds of tech), despite various serial memory standards. Another example is ethernet where QSFP's are just x4 serial lines.. aka in parallel. SAS x4, etc. So, these days like RISC/CISC its hard to be 100% correct calling some of these technologies pure serial or parallel.

cogman10 5y ago
I don't really agree with your classification of serial v parallel. With a parallel port line, if you trim any line, the entire port is dead. What we now do is multiple serial lines sending data in parallel, but still in a serial fashion (IE, encoding data rate and clock information per line). If you cut a serial line, data still flows. (even with something like PCI-Express). The key distinction is a parallel bus has effectively a single clock for the arrival of data whereas serial lines are allowed to have data flow at different rates per line. Serial lines require more hardware at either end to work effectively but ultimately don't have the timing and cable length issues that plague parallel bus transmissions. Though, I admit this is probably the same as quibbling over using threads vs forking for concurrency.
- StillBored 5y ago
  I figured someone would say this (each bit clocked in parallel), but there are a lot of other things one can use in an attempt to quantify whether something is "serial or parallel" and I don't think at the highest level any of them count more than whether or not your physically sending multiple bits in parallel down multiple wires. Oh, and BTW, you can cut data lines on any number of "parallel" buses like DDR and they can frequently continue to work because there are extra ECC/parity lines which can recover the original data, or they are packetized and can recover/detect errors. Particularly on die/board level clocked interconnect buses which don't have as much complexity as the longer distance, outside the chassis interconnects. OTOH, a single serial line is done if it gets cut. You can only fix that by... ganging them in parallel. (edit: I keep tweaking this, but clock recovery isn't a hallmark of serial lines either, as there are plenty of things traditionally considered serial that have separate clock lines and have the same problems that happen on what one might consider a traditional parallel bus when run at high enough frequency)

cogman10 5y ago

I don't really agree with your classification of serial v parallel. With a parallel port line, if you trim any line, the entire port is dead. What we now do is multiple serial lines sending data in parallel, but still in a serial fashion (IE, encoding data rate and clock information per line). If you cut a serial line, data still flows. (even with something like PCI-Express). The key distinction is a parallel bus has effectively a single clock for the arrival of data whereas serial lines are allowed to have data flow at different rates per line. Serial lines require more hardware at either end to work effectively but ultimately don't have the timing and cable length issues that plague parallel bus transmissions. Though, I admit this is probably the same as quibbling over using threads vs forking for concurrency.

StillBored 5y ago
I figured someone would say this (each bit clocked in parallel), but there are a lot of other things one can use in an attempt to quantify whether something is "serial or parallel" and I don't think at the highest level any of them count more than whether or not your physically sending multiple bits in parallel down multiple wires. Oh, and BTW, you can cut data lines on any number of "parallel" buses like DDR and they can frequently continue to work because there are extra ECC/parity lines which can recover the original data, or they are packetized and can recover/detect errors. Particularly on die/board level clocked interconnect buses which don't have as much complexity as the longer distance, outside the chassis interconnects. OTOH, a single serial line is done if it gets cut. You can only fix that by... ganging them in parallel. (edit: I keep tweaking this, but clock recovery isn't a hallmark of serial lines either, as there are plenty of things traditionally considered serial that have separate clock lines and have the same problems that happen on what one might consider a traditional parallel bus when run at high enough frequency)