kernel/linux/Documentation/networking/PLIP.txt

   1 PLIP: The Parallel Line Internet Protocol Device
   2
   3 Donald Becker (becker@super.org)
   4 I.D.A. Supercomputing Research Center, Bowie MD 20715
   5
   6 At some point T. Thorn will probably contribute text,
   7 Tommy Thorn (tthorn@daimi.aau.dk)
   8
   9 PLIP Introduction
  10 -----------------
  11
  12 This document describes the parallel port packet pusher for Net/LGX.
  13 This device interface allows a point-to-point connection between two
  14 parallel ports to appear as a IP network interface.
  15
  16 What is PLIP?
  17 =============
  18
  19 PLIP is Parallel Line IP, that is, the transportation of IP packages
  20 over a parallel port. In the case of a PC, the obvious choice is the
  21 printer port.  PLIP is a non-standard, but [can use] uses the standard
  22 LapLink null-printer cable [can also work in turbo mode, with a PLIP
  23 cable]. [The protocol used to pack IP packages, is a simple one
  24 initiated by Crynwr.]
  25
  26 Advantages of PLIP
  27 ==================
  28
  29 It's cheap, it's available everywhere, and it's easy.
  30
  31 The PLIP cable is all that's needed to connect two Linux boxes, and it
  32 can be built for very few bucks.
  33
  34 Connecting two Linux boxes takes only a second's decision and a few
  35 minutes' work, no need to search for a [supported] netcard. This might
  36 even be especially important in the case of notebooks, where netcards
  37 are not easily available.
  38
  39 Not requiring a netcard also means that apart from connecting the
  40 cables, everything else is software configuration [which in principle
  41 could be made very easy.]
  42
  43 Disadvantages of PLIP
  44 =====================
  45
  46 Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
  47 Can only be used to connect three (?) Linux boxes. Doesn't connect to
  48 an existing Ethernet. Isn't standard (not even de facto standard, like
  49 SLIP).
  50
  51 Performance
  52 ===========
  53
  54 PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
  55 it *is* getting late. EOB)
  56
  57 PLIP driver details
  58 -------------------
  59
  60 The Linux PLIP driver is an implementation of the original Crynwr protocol,
  61 that uses the parallel port subsystem of the kernel in order to properly
  62 share parallel ports between PLIP and other services.
  63
  64 IRQs and trigger timeouts
  65 =========================
  66
  67 When a parallel port used for a PLIP driver has an IRQ configured to it, the
  68 PLIP driver is signaled whenever data is sent to it via the cable, such that
  69 when no data is available, the driver isn't being used.
  70
  71 However, on some machines it is hard, if not impossible, to configure an IRQ
  72 to a certain parallel port, mainly because it is used by some other device.
  73 On these machines, the PLIP driver can be used in IRQ-less mode, where
  74 the PLIP driver would constantly poll the parallel port for data waiting,
  75 and if such data is available, process it. This mode is less efficient than
  76 the IRQ mode, because the driver has to check the parallel port many times
  77 per second, even when no data at all is sent. Some rough measurements
  78 indicate that there isn't a noticeable performance drop when using IRQ-less
  79 mode as compared to IRQ mode as far as the data transfer speed is involved.
  80 There is a performance drop on the machine hosting the driver.
  81
  82 When the PLIP driver is used in IRQ mode, the timeout used for triggering a
  83 data transfer (the maximal time the PLIP driver would allow the other side
  84 before announcing a timeout, when trying to handshake a transfer of some
  85 data) is, by default, 500usec. As IRQ delivery is more or less immediate,
  86 this timeout is quite sufficient.
  87
  88 When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
  89 per second (where HZ is typically 100 on most platforms, and 1024 on an
  90 Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
  91 On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
  92 quite possible for the trigger timeout to expire between two such polls, as
  93 the timeout is only 500usec long. As a result, it is required to change the
  94 trigger timeout on the *other* side of a PLIP connection, to about
  95 10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
  96 this timeout is required on both sides.
  97
  98 It appears that in practice, the trigger timeout can be shorter than in the
  99 above calculation. It isn't an important issue, unless the wire is faulty,
 100 in which case a long timeout would stall the machine when, for whatever
 101 reason, bits are dropped.
 102
 103 A utility that can perform this change in Linux is plipconfig, which is part
 104 of the net-tools package (its location can be found in the
 105 Documentation/Changes file). An example command would be
 106 'plipconfig plipX trigger 10000', where plipX is the appropriate
 107 PLIP device.
 108
 109 PLIP hardware interconnection
 110 -----------------------------
 111
 112 PLIP uses several different data transfer methods.  The first (and the
 113 only one implemented in the early version of the code) uses a standard
 114 printer "null" cable to transfer data four bits at a time using
 115 data bit outputs connected to status bit inputs.
 116
 117 The second data transfer method relies on both machines having
 118 bi-directional parallel ports, rather than output-only ``printer''
 119 ports.  This allows byte-wide transfers and avoids reconstructing
 120 nibbles into bytes, leading to much faster transfers.
 121
 122 Parallel Transfer Mode 0 Cable
 123 ==============================
 124
 125 The cable for the first transfer mode is a standard
 126 printer "null" cable which transfers data four bits at a time using
 127 data bit outputs of the first port (machine T) connected to the
 128 status bit inputs of the second port (machine R).  There are five
 129 status inputs, and they are used as four data inputs and a clock (data
 130 strobe) input, arranged so that the data input bits appear as contiguous
 131 bits with standard status register implementation.
 132
 133 A cable that implements this protocol is available commercially as a
 134 "Null Printer" or "Turbo Laplink" cable.  It can be constructed with
 135 two DB-25 male connectors symmetrically connected as follows:
 136
 137     STROBE output       1*
 138     D0->ERROR   2 - 15          15 - 2
 139     D1->SLCT    3 - 13          13 - 3
 140     D2->PAPOUT  4 - 12          12 - 4
 141     D3->ACK     5 - 10          10 - 5
 142     D4->BUSY    6 - 11          11 - 6
 143     D5,D6,D7 are   7*, 8*, 9*
 144     AUTOFD output 14*
 145     INIT   output 16*
 146     SLCTIN      17 - 17
 147     extra grounds are 18*,19*,20*,21*,22*,23*,24*
 148     GROUND      25 - 25
 149 * Do not connect these pins on either end
 150
 151 If the cable you are using has a metallic shield it should be
 152 connected to the metallic DB-25 shell at one end only.
 153
 154 Parallel Transfer Mode 1
 155 ========================
 156
 157 The second data transfer method relies on both machines having
 158 bi-directional parallel ports, rather than output-only ``printer''
 159 ports.  This allows byte-wide transfers, and avoids reconstructing
 160 nibbles into bytes.  This cable should not be used on unidirectional
 161 ``printer'' (as opposed to ``parallel'') ports or when the machine
 162 isn't configured for PLIP, as it will result in output driver
 163 conflicts and the (unlikely) possibility of damage.
 164
 165 The cable for this transfer mode should be constructed as follows:
 166
 167     STROBE->BUSY 1 - 11
 168     D0->D0      2 - 2
 169     D1->D1      3 - 3
 170     D2->D2      4 - 4
 171     D3->D3      5 - 5
 172     D4->D4      6 - 6
 173     D5->D5      7 - 7
 174     D6->D6      8 - 8
 175     D7->D7      9 - 9
 176     INIT -> ACK  16 - 10
 177     AUTOFD->PAPOUT 14 - 12
 178     SLCT->SLCTIN 13 - 17
 179     GND->ERROR  18 - 15
 180     extra grounds are 19*,20*,21*,22*,23*,24*
 181     GROUND      25 - 25
 182 * Do not connect these pins on either end
 183
 184 Once again, if the cable you are using has a metallic shield it should
 185 be connected to the metallic DB-25 shell at one end only.
 186
 187 PLIP Mode 0 transfer protocol
 188 =============================
 189
 190 The PLIP driver is compatible with the "Crynwr" parallel port transfer
 191 standard in Mode 0.  That standard specifies the following protocol:
 192
 193    send header nibble '0x8'
 194    count-low octet
 195    count-high octet
 196    ... data octets
 197    checksum octet
 198
 199 Each octet is sent as
 200         <wait for rx. '0x1?'>   <send 0x10+(octet&0x0F)>
 201         <wait for rx. '0x0?'>   <send 0x00+((octet>>4)&0x0F)>
 202
 203 To start a transfer the transmitting machine outputs a nibble 0x08.
 204 That raises the ACK line, triggering an interrupt in the receiving
 205 machine.  The receiving machine disables interrupts and raises its own ACK
 206 line.
 207
 208 Restated:
 209
 210 (OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
 211 Send_Byte:
 212    OUT := low nibble, OUT.4 := 1
 213    WAIT FOR IN.4 = 1
 214    OUT := high nibble, OUT.4 := 0
 215    WAIT FOR IN.4 = 0