samba - Jun 1998 - Slow Printing (2nd Attempt)

( I thought I sent this message out before, but never saw it in the digests )

  Configuration :

     Windows NT 4.0 clients printing to Samba 1.9.18p8 running on Solaris
     2.6/2.51 machines.  The Samba servers are setup like this :

     ...
     security = server
     password server = %m
     encrypt passwords = yes
     networkstation user login = no
     ...

     So the server uses the client as the password server.
     

  Problem :

     Bringing up a print dialog from any application on the NT clients, or
     bringing up the properties dialog for any printer takes between 10 to
     30 seconds or more.

     A debug run at level 10 shows the client and server doing the 
     authentication chat.  I've also just noticed that the server
     also runs the 'lpq command' for each printer the client has
installed
     whenever I open the "Printers" folder on the client, or whenever
I
     attempt to print/get properties of any one of the printers.
     I would guess that is adding to the slow response if not being the 
     sole cause of it.

     Is this expected behavior ?  Is there a way to tune this ?  Is the 
     'lpq command' supposed to run for all printers each time I open the
     "Printers" folder ?

     Or is it the authentication chat that is taking so long ?

     Any tips/pointers/help/patches are greatly appreciated.

     --Craig

Craig Huckabee 				E-Mail : huck@cs.wisc.edu
Computer Systems Lab, Computer Sciences Department			
University of Wisconsin-Madison
http://www.cs.wisc.edu/~huck/

On Fri, 26 Jun 1998, Craig Huckabee wrote:

[snip]
>      Bringing up a print dialog from any application on the NT clients, or
>      bringing up the properties dialog for any printer takes between 10 to
>      30 seconds or more.
> 
>      A debug run at level 10 shows the client and server doing the 
>      authentication chat.  I've also just noticed that the server
>      also runs the 'lpq command' for each printer the client has
installed
>      whenever I open the "Printers" folder on the client, or
whenever I
>      attempt to print/get properties of any one of the printers.
>      I would guess that is adding to the slow response if not being the 
>      sole cause of it.
[snip]

We had a similar problem here.  We have our Samba server print to our HP
LaserJet via TCP/IP to the JetDirect card.  When Windows looks for print
queue information it asks the Samba server which runs lpq to find out the
status of the jobs.  lpq looks not only at the queue on the server but
also what is going on at the printer.  Here it's important to note that HP
JetDirect cards can only accept one TCP/IP connection at a time.  If there
is a job being sent to the printer (or anything else that would use a
connection, such as administrative telnet) lpq must sit there and wait
until either the connection closes or it times out.  Since Windows is
waiting on lpq and lpq is waiting on the printer you end up waiting on
Windows.

What we did here is to set the lpq command to return an empty file so
there would be no delay.  For example, in smb.conf we have:
lpq command = /bin/cat /etc/fake-lpq/%p

and inside the /etc/fake-lpq directory we have a file called
"noentries"
that contains just "no entries" to simulate what our lpq returns when
there is nothing in the queue.  Then we symlinked a file after each of our
queues to the noentries file.

This has removed all the delay we were experiencing.  It does have the
downside of not being able to see any print jobs from the Windows
workstations but that doesn't impact us too greatly.  All the people here
that know what a print queue is also know how to handle it from Linux, the
rest just noticed their computers getting faster :).

For reference we are running a Red Hat 5.0 system with the latest Samba
RPM (samba-1.9.18p8-50.1) and the default lpr system. 

I hope this helps, or at least gives you a place to start looking.

Best,
Sean

------------------------------------------
 Sean E. Millichamp, Consultant
 Ingematics - A Division of Compu-Aid, Inc.