From: levine@regent.enet.dec.com (Rick LeVine)
Subject: Re: TCP/IP and network printers. RE: comp.periphs.printers 4697
Summary: Network Printing Discussion
Keywords: network printing, lpd, tcp/ip, printservers
Organization: Digital Equipment Corporation
Date: Tue, 13 Oct 1992 15:17:37 GMT

I felt some of the replies to my Network Printing Architecture posting 
required a response. I have replied to several at once here:

FIRST:
##Aki Atoji              Unix, X, Networking and Embedded Realtime Consulting
##           aki@akix.uucp                      crash!akix!aki@trout.nosc.mil
##
##
##network printing 'architecture' belongs to triviality from the user's
##point of view.

	My original note was in response to a question about architectures.

##that is really needed is that I (as a user) can just plug it in, power
##it up, and print what I need, when I need it at decent speed.

	Our goal as well. read on.

##noticably?  For one thing, TCP/IP already implies that you look at packet
##headers at least once if not more.  That doesn't really prohibit
##printing at speeds above 20ppm.

	TCP/IP has all the bandwidth one needs. It is LPR that prohibits
	printing of images at 20-30 ppm. When I say images I mean IMAGES,
	scanned and faxed data. The CPAP protocol (which is in the process
	of becoming an RFP) can more than DOUBLE the performance. 


##I don't quite understand this.  I can't really imagine any printer
##company dumb enough to use a protocol which ends up in such an alias.

	Any single channel protocol is prone to mistaking a sequence of
	bits in an image for a control character. The only sure way to avoid
	making that mistake is to NOT LOOK to the data stream for EOF,EOJ, etc,
	but rather use a second logical control channel to tell you when 
	you are done.

##For one thing, lpd remote protocol is in widespread use for TCP/IP
##network printing since it is the most compatible.  While CPAP may be
##technologically better, if that is going to limit my host machines to
##Ultrix and printers to DEC PrintServer, I'd rather print with more
##primitive lpd interface on PC's, Suns, IBM, and even on a (gulp) DEC
##VAX (or even 386's these days) running BSD.

	Thank you for giving me the opportunity to be more specific. I
	should have said more in my original memo but it was getting too long.

	first... host machine...

	PrintServer software is available today for the following platforms:
	VMS, ULTRIX, OSF/1, SunOs, and a source kit that will work on 
	any BSD system that has real BSD printing implemented.

	In the next few months you will be hearing more about this, as
	we are currently engineering new sofware for new platforms that 
	make this sampling of platforms look small. (anyone interested
	in these details now would have to contact me directly to arrange
	legally binding nondisclosure)

	second... the lpd (lpr) interface...

	With our PrintServer software installed on your BSD (see list above)
	system, you still USE THE SAME USER INTERFACE 

	lpr -PPrintServer32 foo.ps
	lpq -PPrintServer32
	lprm ...

	In fact the SUN's PRINTTOOL even works with our software on SUNS. 
	Any application that currently prints via lpd will work. We have
	seamlessly merged with the existing print system. We work very hard to
	maintain the integrety of the original user interface for any platform
	we port to.
	
##I can't see how general purpose workstations are not adequate enough
##to handle daily workload of network printer (which is how much?).

	It is not a "daily workload issue". It is a suitability-for-task
	issue. Our controllers are not just a CPU; we have CCITT decompression
	hardware on the controller board AND we have DMA hardware on the
	controller board. All of which are better suited for printing needs
	than a general purpose system.

##This makes little sense.  If this was the case, is HP out of their
##mind by putting 29K RISC in every LJIIIsi sold?  RISC CPU's tend to
##have lower overhead entering interrupts (see for yourself in Intel
##960, AMD 29K and MIPS 3051 data books) compared with CISC CPU's such
##as 68K, resulting in gaining popularity in embedded market.

	We arent using a 68000, not by a longshot. We are using a
	114mhz S.O.C. (system-on-a-chip VAX 4000 cpu), which is running
	a military-specification realtime operating system (please,
	no VMS or ULTRIX jokes, ok?) that handles all of the competing
	needs of a network printer and applies most of the cpu horsepower
	to the top-priority task of imaging the page.


##Also, you can't seriously mean that hardware bit-banging is CISC
##speciality.

	Not the CPU itself, the DMA hardware.

##printers.  But a lot depends on the RIP (yes, the *firmware*) as well
##as how fast clocking for which CPU you use as far as speed goes.

	Agreed. That is why we use and endorse ADOBE PostScript. That,
	combined with the hardware features above, does the job very well...

##It seems that the CPU speed required to achieve fully sustained >
##30ppm CCITT expansion speed would add too much to the cost.  On the
##other hand, a CCITT compresson/decompression chip is available which
##can do it for less cost.  Which route you take seem to have little to
##do with elegance, but rather, more like common sense.

	Any way you want to slice it, we have software that can print
	CCITT images on our 20 ppm PrintServer at 20 ppm (21 ppm!)
	and on our 32 ppm PrintServer at 28 ppm. You said it yourself;
	all the customer wants is for the thing to print. 

	We dont charge a penny extra for the image decompression hardware;
	it is a standard feature, and we are still cheaper than the
	competition (and they dont have it).


##Yes, but so does laser printer engines.  Or you mean that say, something
##like a big 20ppm engine which contains many moving parts, bearings,
##and motors have higher MTBF than a high quality hard disk with less
##moving parts, bearings and motors?  Heat, may be.  Cost, certainly.
##But greatly reduced reliability?

	No, what Im saying is that a 20 or 32 ppm engine alone is more reliable
	than that same engine PLUS a hard disk with its moving parts, bearings,
	motors, power supply demands, heat, vibration sensitivity, and cables.
	Hope that makes more sense to you now. Simple statistics. Increased
	physical complexity = decreased MTBF.

##I didn't start this off to flame, but it seems as though it has come
##close enough.  

	No problem. You caused me to clarify my original memo, which 
	cant hurt.

##Don't get me wrong.  DEC certainly has great networking printer
##products that deserve close evaluation for those who are shopping for
##high speed and high volume printing.

	Since you posted this publicly, I assume you dont mind if
	we quote you?   ;^)


##I don't develop printer code or hardware much more, except for my own
##leisure :).  For the most part, like I said earlier, I want to just
##hook the thing up, load paper, edit printcap then type 'lpr' just like
##what the man page says on the Suns and other workstations, a PC on a
##Netware, PC on a LANMAN, and PC with TCP/IP loaded, or even from an
##OS/2 box.

	For the most partyou have described the installation procedure,
	except that we provide a new man page that tells you about the
	extra features, like multi-page layup, which is all part of the kit.
	This of course only applies TODAY to VMS, ULTRIX, OSF/1, SunOs, and
	any BSD systems. But that is a start.... more later...

>>------------------------------------------------------------------------------- 

And now, part two, in response to:
##Fred Fierling    fff@microplex.com      Tel: 604 875-1461   Fax: 604 875-9029
##Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC  V5T 1A7,  Canada


##Not true.  The transport layer of TCP/IP is completely transparent and
##indifferent to data passing through it.  Only LPD print filters and that
##portion of a printer that implements a print language parse the incoming
##stream.

	It is the LPD filters I am talking about. We implement the
	CPAP protocol on BSD systems as a replacement for the filter(s)
	which speaks on two channels at once, and thereby doubles performance
	and eliminates "aliasing" problems.

##Once again, parsing of the data is handled by the printer's interpreter, not
##the transport layer.  TCP/IP sends a packet full of control D's just as well
##as one full of spaces.  If a printer interprets control D's as end of job,
##then its language will have some extension to encode any image data that
##happens to be a control D.

	Ah, but there are two layers in a networked printer. The communications
	layer is getting the data from the network and passing it to the
	interpreter. The interpreter is parsing the data for PDL (page
	description language) commands. 


	In a single channel model, the network layer has to parse every incoming
	byte soit knows when it hits EOF and can decide that is the end of file,
	or end of job. This means every byte is read twice; once by the network
	layer, and once by the interpreter. For a 5 megabyte file, that is
	10 megabytes wiorth of parsing...

	CPAP eliminates this one layer of parsing by means of a control
	channel.(the communications layer in the printer never parses the 
	contents of a packet of data, just passes the data to the interpreter. 
	any EOF or EOJ is communicated on a different channel.) This effectively
	doubles performance for large files.

##CPAP sounds very interesting, and I'm sure it's a very well thought out
##network printing standard.  But LPD is already out there.  Many machines
##from many different manufacturers already use LPD.  Are there plans to
##promote CPAP as an open standard (say, in an RFC), or will it only be
##available in DEC equipment?

	It is a proposed RFP now. Our goal is exactly what you say above; to
	see it promoted as an open standard.

	And the client end, as I said above, is currently available for
	a variety of non-DEC platforms. More on the way, too...



Comments and replies are welcome...

Rick LeVine				levine@regent.enet.dec.com
PrintServer Systems Engineering
Digital Equipment Corporation
Westford, MA 

Newsgroups: comp.periphs.printers