Bug 2232 - Slow printing of larger print jobs on parallel ports
Summary: Slow printing of larger print jobs on parallel ports
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lpr
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-17 10:49 UTC by yan
Modified: 2014-03-17 02:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-10-27 22:55:11 UTC

Attachments (Terms of Use)

Description yan 1999-04-17 10:49:55 UTC
RH 5.2, using lp0-2, 2.0.36 kernel.

If the print job is large (bigger than 1 MB or so, though
this appears to vary; sometimes jobs as small as 200K
suffer from this) printing performance drops drastically.
From timing the printer, it sits idle for 60-90 seconds,
then gets about a 5 second burst of data, then sits idle for
another 60-90 seconds.

I started with lp.c compiled as a module; then, thinking
that maybe kerneld is unloading the lp module, I tried
upping the unload time to 600, then 6000 seconds.  No
diffference. I recompiled the kernel with lp.  No change in

This appears consistent whether or not I use irqs or
polling.  The deciding factor is the size of the print job.

Below a certain size, the print job prints very quickly;
using polling, lpd sucks down about 60% of cpu cycles.
Beyond a certain size, lpd begins using very little cpu and
performance drops accordingly.

I've used tunelp and tried recompiling lp.c with various
parameters; still no joy.  Beyond a certain size, the
send-wait-send printing starts.

tunelp parameters do not "stick".  I don't know if this is
related, but if I use tunelp, the values I set are only in
effect for a few minutes, then revert to whatever is
compiled into lp.c.

This is consistent.  I had the same problem with a hacked up
5.1, and now with a clean install of 5.2.

I am printing to a Xerox C55 (a nice color laser) using
postscript.  I have eliminated all ghostscript stuff from
printcap.  There may be an incompatibility between some
printers and the way RH handles the lp ports (or possibly
some parallel port hardware).  I see similar behavior on an
HP 350C plotter (send-pause-send) but not on an old HP
LaserJet II printer.  The Xerox is best at self-diagnosis,
so I use it for testing this.  The Xerox also does not
appear to get a "end of document" signal; it sits and waits
for additional data and sometimes does not go into "sleep"

By comparison, I ran the same print job using the Xerox
printer, a 6 MB graphic image on the linux box and on a
nearly identical NT 4.0 server.  The linux print job took 40
minuts or so; the NT job took 4 minutes.  The graphic image
was generated using Corel Photo-Paint on an NT 4.0 WS.

Both boxes are p5-166s; the linux box has 64 MB RAM and the
NT box has 32 MB RAM.

Others have experienced this as well.  Ther have been some
posts on the redhat and linux groups on this topic.


Comment 1 Michael K. Johnson 1999-05-11 16:36:59 UTC
Does your computer have BIOS settings for ECP/EPP modes?  If so,
have you tried toggling them to see if it makes a difference?

FWIW, tunelp parameters "not sticking" is due to the module
unloading; you can put a postinstall into /etc/conf.modules to
run tunelp after loading the lp module and set the parameters

Comment 2 Michael K. Johnson 1999-08-28 19:28:59 UTC
As far as an "end of document" signal, printtool has the option
to send an end-of-file ^D character.

As far as the rest goes, one counter-intuitive thing to try is to
*slow down* transmission.  This could be a race condition in the
printer where it doesn't know that it isn't full...  Hard to trace
for sure without a logic analyzer or at least writing a debugging
version of the lp module and spending hours poring over it...

The parallel port driver code was substantially re-written for the
2.2 kernel; it would be worth checking to see if Red Hat Linux 6.0
solves this problem if you have available machines and disk space
and time...

I doubt that lpr really has anything to do with the problem; you
might try sending the postscript file straight to the /dev/lp1
(or /dev/lp2 or /dev/lp0...) port with
cat filename > /dev/lp1
and see if you get the same results.

Comment 3 Bill Nottingham 1999-10-27 22:55:59 UTC
closed, lack of input.

Note You need to log in before you can comment on or make changes to this bug.