
		XNET-1 SYNC card driver usage notes

	XNET-1 card from  Internet Technologies International OY,
	Helsinki, Finland  <intec@digiw.fi>
		Internet Technologies International OY (Ltd)
		PO BOX 51
		00641 Helsinki
		FINLAND
	Fax: +356-0-7523939

	Driver, and documentation, copyright Internet Technologies
	International OY, 1995.   Distribution is according to GNU
	Public License version 2, or latter.


			Card features:

	- 8-bit PC/ISA-bus card
	- Uses one IRQ
	- Uses TWO DMA-channels
	- Maximum datarate for Sync-PPP is 800 kbps on an 486/33
	  (Time needed for IRQ processing, and DMA-setup for data
	   reception limits max speed.)  If sending system can
	  introduce delay in between HDLC frames, bit-rate in frames
	  can be raised up to 2 Mbps.
	- Resource limitations on system (8-bit DMAs) limit
	  to ONLY ONE CARD PER MACHINE.
	- Electrical interface is X.21, which can be used
	  to interface with V.35 with suitable cable, however
	  all signals can't be supported in that case.
	- Has 15-pin male connector for X.21.
	- Has 9-pin male connector for RS-232. (``Port B'')
	- Uses serial chip NEC D72001C-11


			Introduction:

	The Card  that is supported with this driver was originally
	intended for 64kbps digital X.21-interfaced networks that were
	``popular'' before the ISDN era -- when the network proper was
	already digitalized, but the local loops were still analog.

	Then came the era of the first ISDN deployment tests with zero,
	or very low rates (expense to customer), and  The Card  was used
	to attach to an ISDN-X.21 interface box at datarate of 64kbps,
	and a driver was developed for it on a SysVr3 variant called ISC
	(Interactive Systems Copr..) with support of X.21 dialup.  This
	Linux version of the driver does not anymore contain all that
	X.21-dialup support code.   (If there is a need for it, we might
	consider putting it back, though..)

	These days the ISDN has (at least in Finland) usually an extra
	per-minute data-charge all day around on it, while the normal
	telephony usually does not have time-charge on call at least in
	the night (17-19 to 07-08).  As a result, the ISDN has lost a
	lot of its appeal on private sector being more expensive, than
	the traditional system.

	Another thing in Finland is that our telecommunication operators
	(local and long-distance) are competing rather furiously, which
	translates to lowest rates of the services anywhere in the world
	( At least this is what several international telecom area magazines
	  claim..  It is also our experience that when we tell our foreign
	  collegues the prices that we pay, they ask: "Are those subsidized?",
	  and they just stare unbelieving when we answer: "No"... )

	Now we use this card to connect on 256kbps leased line with a
	V.35 interfaced modem, and it works on a machine with 486/33,
	but it is pushing the performance envelope a bit too close.
	( IRQ response time is now squeezed to circa 40 microseconds,
	  which is mightly low, but note that octet time at that speed
	  is 31.25 microseconds.  There is also a 4 byte FIFO, which
	  means that with ``shared flag'' mode we have circa 5 octet-
	  times before new DMA-buffer must be in use.  With non-shared
	  HDLC flags we have circa 6 octet times..  That is 156 - 187
	  microseconds at 256 kbps. )

	RECOMMENDATION:  AT HIGH SPEEDS, USE THIS CARD ON DEDICATED ROUTER
			 MACHINE, OR YOU MAY RISK LOOSING SOME PACKETS!

	To be exact we DO NOT SUPPORT ALL V.35 SIGNALS WITH THIS CARD, only
	the essential ones used on leased line.  (Recall previous talk about
	the origins:  X.21)    In practice this means the modem must be
	configured for "always on, leased line" -mode, but any sensible
	modem should be able to do it, anyway..

	The Card  has also a Port-B with a 9-pin RS-232, however this driver
	does not support the use of that port. (It could be used to supply
	the missing RS-232-level signals for full V.35, though...)


			Driver installation:

	The driver is modularized so that it does not need kernel source
	modifications and subsequent kernel recompile to be installed on
	the system.

	Supported kernels are at the moment (21.7.-95) the 1.2.* series,
	of which the 1.2.11 was used when developing.  (Kernels 1.3.*
	are also supported, but code is not tested on them - 25-jul-95)

	If you change kernel version, and you use  "CONFIG_MODVERSIONS"
	then you MUST recompile this driver as well.  See below.



	Building and installing instructions follow:

	1) Unpack the  xnet(version).tar.gz  into your favourite
	   location (/usr/src, for example)

		$ cd /usr/src
		$ tar xzvvf ..../path/to/xnet.tar.gz

	2) CD to (e.g.) /usr/src/xnet/  where the package opened:

		$ cd xnet

	3) Edit   rc.xnet, and perhaps Makefile, see comments

		$ emacs rc.xnet Makefile

	4) Compile and install:

		$ make
		...
		$ su
		....
		# make install

	4) Edit  /etc/rc.d/rc.local, or /etc/rc.d/rc.M  to call
	   now installed   /etc/rc.d/rc.xnet  at the startup.


	On next system reboot the  xnetpppd  starts taking care of the
	link, and bytes start flowing.


			Cabling instructions:

	? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?


			Future directions:

	This is using our own PPP state-machine, mostly because it
	was easiest to integrate into use with our card, however the
	Linux-PPP (2.3 perhaps ?) will contain a completely different
	strategy of doing things.  Right now it is a sort of TTY driver,
	but the dream is to change it into an  SOCK_PPP -- that is,
	instead of opening up a TTY, we create a  socket(), and attach
	that to a proper interface device.   Such will change internals
	dramatically, and do away all the PPP-code built into our driver
	(not only our separate  xnetpppd...)

	For more about that dream, join the   linux-ppp@vger.rutgers.edu.
	( Subscriptions via  majordomo@vger.rutgers.edu )

