plip.rst 8.2 KB

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