Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 |