1 |
1275 |
phoenix |
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 |
|
|
|
201 |
|
|
>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
|