4 ms·

Linux support IP over the same cable, it's known as PLIP, parallel-port Internet. It was the only way to access the outside world on my Toshiba T1800 laptop.

Linux support IP over the same cable, it's known as PLIP, parallel-port Internet. It was the only way to access the outside world on my Toshiba T1800 laptop. However it wasn't fast (23 kB/s IIRC) and it completely bogged down the host (no hardware acceleration there). There were experimental work on "8-bit PLIP", but the hardware wasn't very standard and in my testing it wasn't actually faster in practice. There was also some kind of DMA standard for the parallel port, but I don't think anyone succeeded in exploiting it for PLIP. The who PLIP experience gave me a new appreciation for IBM's hardware accelerated "channels" concept - something we never got with x86 given its origin.

gattilorenz 4y ago
> It was the only way to access the outside world on my Toshiba T1800 laptop Didn't it have a serial port?
- cogman10 4y ago
  What was wild to me is learning that serial communication is almost always faster than parallel communication. Turns out, synchronizing arriving signals is hard.
  - StillBored 4y ago
    " 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 4y 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 4y 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)
- FullyFunctional 4y ago
  Sorry, it's ~30 years ago and my memory was faulty as I checked and it did have one. However, I didn't use it so it must have been slower than PLIP.
netsharc 4y ago
Windows 9x did as well. It was a cheap way for my brother to be able to go online without extra hardware like network cards: I'd dial up the ISP from my computer, and he'd open up a parallel-to-parallel connection. I had Proxomitron running (ah, the good old days of HTTP proxy as an ad blocker) and on his browser he'd set that up as the proxy server and be able to go online.
retrac 4y ago
> However it wasn't fast (23 kB/s IIRC) and it completely bogged down the host (no hardware acceleration there). In the most basic fallback mode, the "uplink" from device to host is actually working 4 bits at a time over the "control" lines. All polled with no interrupts. The driver spends most of its time in a busy loop. The parallel port eventually did eventually get quite fancy in the 90s, with buffered, interrupt-driven bidirectional communication possible in ECP mode (~2 MB/s). But USB was already on the rise by then and it was basically obsolete by the time drivers and motherboards widely supported it.
- u801e 4y ago
  IIRC, you could only utilize ECP mode with a laplink brand cable (which would give you the faster transfer rate). Otherwise, you had to use EPP. I used the latter with a regular parallel cable with an adaptor I soldered with a certain pin to pin configuration.
  - LargoLasskhyfv 4y ago
    It depended on the quality of the IO-chipset on your board, or cards. I remember experimenting with that between 91 to 94, and got it up to 4Mbit/s via parallel with ECP/EPP-DMA something. I also used something looking exactly like this http://www.cablesonline.com/rsdbbreakbox.html http://www.cablesonline.com/rsdbbreakbox.html with gender changers. Imagine the red/green blinkenlights! But that was mostly just for fun, I already had Ethernet.
TacticalCoder 4y ago
Darn, you beat me to it! I just posted a similar comment. I also had some old Toshiba laptop and I'd use PLIP between that laptop and my PC. I don't remember it being particularly slow though: but it was many moons ago so...

gattilorenz 4y ago

> It was the only way to access the outside world on my Toshiba T1800 laptop Didn't it have a serial port?

cogman10 4y ago
What was wild to me is learning that serial communication is almost always faster than parallel communication. Turns out, synchronizing arriving signals is hard.
- StillBored 4y ago
  " 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 4y 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 4y 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)
FullyFunctional 4y ago
Sorry, it's ~30 years ago and my memory was faulty as I checked and it did have one. However, I didn't use it so it must have been slower than PLIP.

netsharc 4y ago

Windows 9x did as well. It was a cheap way for my brother to be able to go online without extra hardware like network cards: I'd dial up the ISP from my computer, and he'd open up a parallel-to-parallel connection. I had Proxomitron running (ah, the good old days of HTTP proxy as an ad blocker) and on his browser he'd set that up as the proxy server and be able to go online.

retrac 4y ago

> However it wasn't fast (23 kB/s IIRC) and it completely bogged down the host (no hardware acceleration there). In the most basic fallback mode, the "uplink" from device to host is actually working 4 bits at a time over the "control" lines. All polled with no interrupts. The driver spends most of its time in a busy loop. The parallel port eventually did eventually get quite fancy in the 90s, with buffered, interrupt-driven bidirectional communication possible in ECP mode (~2 MB/s). But USB was already on the rise by then and it was basically obsolete by the time drivers and motherboards widely supported it.

u801e 4y ago
IIRC, you could only utilize ECP mode with a laplink brand cable (which would give you the faster transfer rate). Otherwise, you had to use EPP. I used the latter with a regular parallel cable with an adaptor I soldered with a certain pin to pin configuration.
- LargoLasskhyfv 4y ago
  It depended on the quality of the IO-chipset on your board, or cards. I remember experimenting with that between 91 to 94, and got it up to 4Mbit/s via parallel with ECP/EPP-DMA something. I also used something looking exactly like this http://www.cablesonline.com/rsdbbreakbox.html http://www.cablesonline.com/rsdbbreakbox.html with gender changers. Imagine the red/green blinkenlights! But that was mostly just for fun, I already had Ethernet.

TacticalCoder 4y ago

Darn, you beat me to it! I just posted a similar comment. I also had some old Toshiba laptop and I'd use PLIP between that laptop and my PC. I don't remember it being particularly slow though: but it was many moons ago so...