About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / networking / PLIP.txt




Custom Search

Based on kernel version 3.9. Page generated on 2013-05-02 23:11 EST.

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
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog
Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.