|Summary:||Slow printing of larger print jobs on parallel ports|
|Product:||[Retired] Red Hat Linux||Reporter:||yan|
|Component:||lpr||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-10-27 22:55:11 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 behavior. 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" mode. 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. Yan
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 there.
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.