Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!mrose@UDEL-DEWEY.ARPA
From: mrose@UDEL-DEWEY.ARPA
Newsgroups: net.unix-wizards
Subject: Re: IMAGEN laser printer slowness
Message-ID: <10057@brl-tgr.ARPA>
Date: Fri, 19-Apr-85 02:22:52 EST
Article-I.D.: brl-tgr.10057
Posted: Fri Apr 19 02:22:52 1985
Date-Received: Sun, 21-Apr-85 02:05:38 EST
Sender: news@brl-tgr.ARPA
Lines: 26

[This conversation should be moved to laser-lovers, but...]

At NRTC, we have a 12/300 with 1.5mb on an ethernet, and as far as I
can tell, the controller *always* drives the print engine at FULL speed,
with the exception of when the banner page gets printed.  That is, the Ricoh
engine and not the IM-II is the bottleneck.

Now, assuming you're using the 4.2bsd spooling software to talk to the IM-II
over the ethernet, for (d)itroff jobs, the bottleneck is probably your host
cpu since the trickle from catimp(dimp) is piped directly to ies which talks
over the net to the controller.  Of course, you'd see this behavior with
any other type of interface to the IM-II as well.

What I can't understand is why "lpr -v" is so slow in printing, all imfilter
does in that case is just call ies on the file you queued.  Granted, that
imfilter being a Cshell script is real slow to start, but once it decides
what it's doing, it should run like lightning.

So, what kind of load do you put on the host driving the controller?
BTW- I've made a lot of changes to the 4.2 imagen stuff (in the one week
we've been using it--it pays to have worked on a 10/240 for a couple of
years), which make it run nicer.  I'll probably get around to talking to Imagen
next week.  

/mtr
213/377-4811