I've googled for this and poked around linuxprinting.org, but couldn't find anything helpful.
I have a CentOS 5 server with an HP LaserJet 4 attached via JetDirect with the hplip driver. The problem is that when I have multiple print jobs in the queue, there is a delay of about 15 seconds between each job. This gets very annoying when there are 10-15 one-page jobs in the queue. "lpstat -t" shows me errors like this:
recoverable: Network host 'seashell' is busy; will retry in 15 seconds...
This worked fine previously with the same setup on an old RedHat release (Either RH7 or RH9, I don't remember which). The problem appeared after I rebuilt the server with CentOS 5.
Any ideas would be appreciated.
On Tue, September 29, 2009 10:49 am, Bowie Bailey wrote:
I've googled for this and poked around linuxprinting.org, but couldn't find anything helpful.
I have a CentOS 5 server with an HP LaserJet 4 attached via JetDirect with the hplip driver. The problem is that when I have multiple print jobs in the queue, there is a delay of about 15 seconds between each job. This gets very annoying when there are 10-15 one-page jobs in the queue. "lpstat -t" shows me errors like this:
recoverable: Network host 'seashell' is busy; will retry in 15seconds...
This worked fine previously with the same setup on an old RedHat release (Either RH7 or RH9, I don't remember which). The problem appeared after I rebuilt the server with CentOS 5.
Any ideas would be appreciated.
-- Bowie _______________________________________________
Have you tried using it as a RAW print que?
Is this when clients are printing to it via the share?
Bo Lynch wrote:
On Tue, September 29, 2009 10:49 am, Bowie Bailey wrote:
I've googled for this and poked around linuxprinting.org, but couldn't find anything helpful.
I have a CentOS 5 server with an HP LaserJet 4 attached via JetDirect with the hplip driver. The problem is that when I have multiple print jobs in the queue, there is a delay of about 15 seconds between each job. This gets very annoying when there are 10-15 one-page jobs in the queue. "lpstat -t" shows me errors like this:
recoverable: Network host 'seashell' is busy; will retry in 15seconds...
This worked fine previously with the same setup on an old RedHat release (Either RH7 or RH9, I don't remember which). The problem appeared after I rebuilt the server with CentOS 5.
Any ideas would be appreciated.
-- Bowie _______________________________________________
Have you tried using it as a RAW print que?
Is this when clients are printing to it via the share?
That's when I usually notice it, but I can duplicate the problem by printing text files via lp as well, so the problem doesn't appear to be related to samba.
How would I set up a RAW queue?
On Tue, September 29, 2009 11:05 am, Bowie Bailey wrote:
Bo Lynch wrote:
On Tue, September 29, 2009 10:49 am, Bowie Bailey wrote:
I've googled for this and poked around linuxprinting.org, but couldn't find anything helpful.
I have a CentOS 5 server with an HP LaserJet 4 attached via JetDirect with the hplip driver. The problem is that when I have multiple print jobs in the queue, there is a delay of about 15 seconds between each job. This gets very annoying when there are 10-15 one-page jobs in the queue. "lpstat -t" shows me errors like this:
recoverable: Network host 'seashell' is busy; will retry in 15seconds...
This worked fine previously with the same setup on an old RedHat release (Either RH7 or RH9, I don't remember which). The problem appeared after I rebuilt the server with CentOS 5.
Any ideas would be appreciated.
-- Bowie _______________________________________________
Have you tried using it as a RAW print que?
Is this when clients are printing to it via the share?
That's when I usually notice it, but I can duplicate the problem by printing text files via lp as well, so the problem doesn't appear to be related to samba.
How would I set up a RAW queue?
-- Bowie
You can do this with cups by selecting make and model as local raw printer. We have had issues similar to this when printing pdf's. One page would print then 10 seconds later the next, so on and so on. Using a raw print que on server and a PostScript driver on the clients seem to work. Bo
Bo Lynch wrote:
On Tue, September 29, 2009 11:05 am, Bowie Bailey wrote:
Bo Lynch wrote:
On Tue, September 29, 2009 10:49 am, Bowie Bailey wrote:
I've googled for this and poked around linuxprinting.org, but couldn't find anything helpful.
I have a CentOS 5 server with an HP LaserJet 4 attached via JetDirect with the hplip driver. The problem is that when I have multiple print jobs in the queue, there is a delay of about 15 seconds between each job. This gets very annoying when there are 10-15 one-page jobs in the queue. "lpstat -t" shows me errors like this:
recoverable: Network host 'seashell' is busy; will retry in 15seconds...
This worked fine previously with the same setup on an old RedHat release (Either RH7 or RH9, I don't remember which). The problem appeared after I rebuilt the server with CentOS 5.
Any ideas would be appreciated.
-- Bowie _______________________________________________
Have you tried using it as a RAW print que?
Is this when clients are printing to it via the share?
That's when I usually notice it, but I can duplicate the problem by printing text files via lp as well, so the problem doesn't appear to be related to samba.
How would I set up a RAW queue?
-- Bowie
You can do this with cups by selecting make and model as local raw printer. We have had issues similar to this when printing pdf's. One page would print then 10 seconds later the next, so on and so on. Using a raw print que on server and a PostScript driver on the clients seem to work. Bo
I set the printer type as raw and then restarted cups just to make sure the change was active. No effect. Still have the delays.
Any other ideas?
On Tue, Sep 29, 2009 at 11:48:07AM -0400, Bowie Bailey wrote:
I set the printer type as raw and then restarted cups just to make sure the change was active. No effect. Still have the delays.
Avoid cups for a quick test:
2 ways:
1) get the lprng rpm and extract lpr and lpq to a directory, both should be usable even with little to no configuration aside the normal host printing setup. The nice effect: things like lprng -Plj@host just work, without adding queues, discovery and other annoyances.
2) just ftp the file to the printer (maybe newer jetdirect cards also support things like ipp / http as well?).
The 2nd method at least reduces the components being tested to the raw network connection between two boxes.
And of course, effects due to funny things being printed (testing with multiple printers and having one set of tests print a single file run thru gs to produce pcl-3 or higher may be a good way to detect funny postscript like strange font embedding (e.g. from the application/library/... on a badly configured client), or full color for a black&white laser, etc).
Peter l Jakobi wrote:
On Tue, Sep 29, 2009 at 11:48:07AM -0400, Bowie Bailey wrote:
I set the printer type as raw and then restarted cups just to make sure the change was active. No effect. Still have the delays.
Avoid cups for a quick test:
2 ways:
- get the lprng rpm and extract lpr and lpq to a
directory, both should be usable even with little to no configuration aside the normal host printing setup. The nice effect: things like lprng -Plj@host just work, without adding queues, discovery and other annoyances.
- just ftp the file to the printer (maybe newer jetdirect
cards also support things like ipp / http as well?).
The 2nd method at least reduces the components being tested to the raw network connection between two boxes.
And of course, effects due to funny things being printed (testing with multiple printers and having one set of tests print a single file run thru gs to produce pcl-3 or higher may be a good way to detect funny postscript like strange font embedding (e.g. from the application/library/... on a badly configured client), or full color for a black&white laser, etc).
I'm not sure avoiding cups would be useful. The problem seems to be with cups getting the print jobs from the queue to the printer. Once the printer finishes a job, it takes cups about 15 seconds to realize that the printer is available for the next job.
-
Bo Lynch -
Bowie Bailey -
Peter l Jakobi