From: aki@akix.UUCP (Aki Atoji)
Subject: Re: TCP/IP and network printers. RE: comp.periphs.printers 4697
Organization: CxS Technologies
Distribution: comp
Date: Fri, 9 Oct 1992 09:22:27 GMT


In article <1992Oct5.192134.2645@nntpd.lkg.dec.com> levine@regent.enet.dec.com (Rick LeVine) writes:

>> #When people say a printer supports TCP/IP (or complain about the
>> #lack of support), what do they really mean?

[stuff deleted]

>> -architecture-
>> 
>>This is the heart of the matter. If you choose the above solution,
>>in which the printer has an on-board workstation and the workstation
>>accepts spooling
>>commands via lpd or telnet, then you have not got a network printing 
>>architecture; what you have is a Value-Added-Reseller solution made of 
>>components from many vendors.

While a good implementation is obviously a requirement for a
successful product, there is yet a different view to look at it.

I used to work at a networked laser printer manufacturer myself.  I
did both the firmware and hardware part of it.  I spent countless days
and nights looking for that out-of-place dots and scan lines, killed
thousands of trees to measure the few percentile increments in
Postscript performance or font cache code improvements.

Then I managed to quit the job to come back to the real world, only to
realize that what seemed so important to us printer people, such as
network printing 'architecture' belongs to triviality from the user's
point of view.

As far as network printer from user's point of view is concnered, all
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.

>The real reason it works so well is that THE INCOMING DATA DOES NOT NEED TO BE
>PARSED in order to find the end of file, etc. Think about the extra work
>required to parse every byte of an incoming 5 megabyte file looking
>for EOF and
>THEN having PostScript re-parse it as it interprets the page info.

While this is a valid point, would a simple character lookup in the
incoming data matter enough that the print speed is affected
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.

>>Performance is NOT the only reason to choose such a robust protocol,
>>though. A major factor in driving this choice was CONTROL CHARACTER
>>ALIASING... if you are reading in an image file under any of the other
>>print protocols and the bits in the image sequence happen to alias
>>a CONTROL D, 99% of the time your job will abort.(Because the printer
>>SAW a CONTROL D). Dual channel means that aliasing is never a problem
>>and no fancy workarounds are needed.

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.
Even something as dumb as SLIP protocol (if you could call it a
protocol) which inserts control characters avoids this.

>As I said above, many other network printing solutions copy the print file
>wholesale to a local hard disk in the printer. For the most part they do this
>because they are emulating a remote lpd "rp=" printer. 

[deleted]

>A network printer with an appropriately thought-out protocol should have the
>same degree of transparent access to files anywhere on the network without
>having to duplicate them locally. The printer should be able to get what it
>needs, on demand, from any host which has a pending print job. That is, in
>a general sense, what Digital's CPAP protocol provides.

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.

[more stuff deleted]
>>Many vendors offer solutions that use
>>general purpose workstation or PC boards. These work as short term solutions
>>but they were not designed with the daily workload of a network printer in
>>mind.

I can't see how general purpose workstations are not adequate enough
to handle daily workload of network printer (which is how much?).

>>Many vendors would have you measure network printer performance in terms of 
>>MIPS, but that is an arbitrary measure and may not have much bearing on
>>how many pages per minute the printer will actually produce under
>>heavy loads.
>>For our PrintServer printers we chose a robust CISC cpu over a purportedly 
>>"faster" RISC cpu. This allows for excellent realtime event handling plus
>>the hardware-enhanced capability of moving bits to the image buffer
>>very fast.

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.

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

And as for computational power and robustness...  Well, I'd rather
have one of them cheap but fast RISC workstation than a 68K based ones
these days, wouldn't you?

I do agree with you that quoting MIPS is a silly thing.  Worse yet,
I've heard SPECmarks used in discussions for selecting a CPU for
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.

>> -intelligence rather than brute force-
>>
>>Our PrintServer family also has on-board CCITT decompression; it allows for
>>multi-megabyte-per-page image printing at 20 PPM on the PrintServer 20,
>>and close to 30 PPM on the new PrintServer 32. In both cases this was
>>accomplished with an elegant on-board hardware architecture, not by the
>>addition of a faster CPU. 

Intelligence and Elegance seem purely subjective.  If CPU is fast
enough (and heck, some of the PostScript output need every cycle you can
get), and if it's not doing anything, why not use it?  While a CCITT
job is printing, the CPU isn't really going to be busy unless it was
expanding CCITT image, isn't it?

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.

[deleted]
>>a hard disk drive into the printer. We considered this as an option, but we
>>found that the addition of a hard disk drive adversely effected the printer's
>>overall reliability.
>>
>>Here are some simple reasons why a hard disk is not necessarily a good thing
>>to have inside a network printer:
>>
>>   -Hard disk drives contain many moving parts, bearings, heads, motors
>>    and they are statistically more likely to fail than solid state
>>    memory-based systems.

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?

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

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.

But I feel that such posting full of marketing commercialism with
certain contradictions and somewhat single sided view deserves certain
scrutiny.

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.



>>------------------------------------------------------------------------------- 
>>Rick LeVine				levine@regent.enet.dec.com
>>Senior Engineer
>>PrintServer Systems Engineering
>>Digital Equipment Corporation
>>Westford, MA 
-- 
---------------------------------------------------------------------------
Aki Atoji              Unix, X, Networking and Embedded Realtime Consulting
           aki@akix.uucp                      crash!akix!aki@trout.nosc.mil
---------------------------------------------------------------------------
Newsgroups: comp.periphs.printers