walton%ll-xn.arpa@ll-xn.arpa (Robert Walton) (04/17/85)
I am interested if anyone knows anything about the speed, or lack thereof,
of the IMAGEN laser printer.
For example, we have a iroff (ditroff) job of 47 pages that
(1) when printed with pagereversal on seems to take 25 minutes
for the imagen printer to process and 5 minutes to print
(2) when printed with pagereversal off (run dimp -t first and edit output
to change `pagereversal on' to `pagereversal off' before using
lpr -v) the first 10 pages take 2 minutes to print (measured from
job header page of previous job) whereas each succeeding 10 pages
takes 8 minutes to print
This is with a new imagen processor with 1.25 Megabytes of memory.
With the same processor and 0.75 megabytes we also noticed the same
slowdown problem as in (2) with imprint -2 -O -F, but the extra memory
cures that.
We are using Ethernet communications, but do not believe the problem
lies in slow communications. The 47 page iroff document above requires
that 179 Kbytes be sent to the IMAGEN processor, about 5 Kbytes per page,
which should be easily doable in 6 seconds per page.
10 pages per 8 minutes is not very good speed, especially since the printer
is bottlenecked during the processing (you cannot precompute everything
overnight as you could with a versatek). Does anyone have any
contrary experience (for large documents) or cure?
We do not claim to have fully and carefully investigated this problem yet,
and are hoping someone out there might know something that would
save us some effort.
Please include `walton at ll-xn' directly in any responses as I am
not on the wizards mailing list.mrose@UDEL-DEWEY.ARPA (04/19/85)
[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