Bug 1538 - Win2K client enum of three SpoolSS / CUPS printers takes 7 seconds
Summary: Win2K client enum of three SpoolSS / CUPS printers takes 7 seconds
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.0.4
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
URL: ftp://ftp.lueckdatasystems.com/pub/fr...
Depends on:
Reported: 2004-07-16 14:25 UTC by Michael Lueck
Modified: 2005-11-14 09:53 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lueck 2004-07-16 14:25:25 UTC
Win2K SP4 client with all hot-fixes current joined to a 3.0.4 PDC on Debian
unstable with a 2.6.x kernel.

Three print queues are defined in CUPS, one as default.
Print drivers have been uploaded to the printer per John's Official HOWTO book.
User level attachments were made to the print queues with the printui.dll with
/in switch used per page 249 in the same book.

Open notepad, type some text, file / print, wait 7 seconds for the dialog to
come up. cancel, file / print, another 7 seconds.

I have turned tracing up to 10 on the server, delete the log just before
pressing the print menu choice and below is what I catch... only 3 seconds worth
of traffic... not sure where the other 4 seconds are coming from, or why this
needs to take so long in the first place.

Saw log entries that Samba was tring to IPC back to the workstation and failed,
ja, we do not run the server task on non-server machines. Turned it on and
rebooted, still a large delay but those errors were no longer in the log.

I have reverted back to PORT based printing which is very fast on the client
side... file / print and boom the dialog is up instantly. So I am only flagging
this as normal as I have a work around prepared for this implementation.

This is on a small test network, 100MB switched, 3GHz client PC's and a 500MHz
test server.


P.S. Bugzilla did not appreciate three seconds worth of logs... I will upload to
a URL and paste that into the URL field...
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-07-21 12:52:01 UTC
I'm not sure this is a bug.  For one, MS's print change notify 
system requires that the server connect back the client.
Not a great design but that's how Windows works.

Secondly, it sounds like you are using a chatty printer 
driver.  There's nothing wrong from what I can tell.
You just can't compare port based printing to 
MS's point-n-print.  It's like comparing apples to oranges.

You can reopen this if you really think there is a bug 
but please compare point-n-print with a Windows based print 
server first.  Thanks.
Comment 2 Michael Lueck 2004-07-21 13:13:02 UTC
Hi Jerry-

I didn't want to have to say it but... I have the exact same configuration
parallel to this Samba test with a Win2K server and SpoolSS printers are
screaming fast. File/Print boom there is the list of printers. (Separate
workstations - I am not dual domain joining the workstations... everything is

I mentioned that turning on the workstation server task did not improve
performance, still a 7 second delay.

How long does File/Print from Notepad for example take to open for you?

Yes I realize Port based printing is Apples vs Oranges... I see this as a three
against one... SpoolSS and Port is fast against Win2K, Port is fast against
Samba, SpoolSS is slow against Samba, thus I consider it a bug.

Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-07-21 13:27:05 UTC

Please send me the following information/files:

(a) a copy of the driver files you are using,

restart the spooler service on the client and 
then send me a

(b) a level 10 debug log from the Samba server 
while printing from notepad
(c) a raw tcpdump of the traffic during the 
same process.

restart the spooler again and then send me 

(d) a raw tcpdump (or netmon capture) performing the same 
action against the 2k print server with the same driver.

Please make sure that turn off the 'advanced features of 
the printer' on the 2k print server to ensure that the 
client is using RAW printing.  

Just mail me the files directly.  Thanks.
Comment 4 Guenther Deschner 2004-07-22 00:33:42 UTC
just as a note: if the traces show that windows tries to do a level4
enumprinters-call, the following article might explain the speed difference.
Would it be hard to mimic that behaviour in samba (or does samba that already) ? 


Windows NT/2000/XP: The PRINTER_INFO_4 structure provides an easy and extremely
fast way to retrieve the names of the printers installed on a local machine, as
well as the remote connections that a user has established. When EnumPrinters is
called with a PRINTER_INFO_4 data structure, that function queries the registry
for the specified information, then returns immediately. This differs from the
behavior of EnumPrinters when called with other levels of PRINTER_INFO_* data
structures. In particular, when EnumPrinters is called with a level 2
(PRINTER_INFO_2) data structure, it performs an OpenPrinter call on each remote
connection. If a remote connection is down, or the remote server no longer
exists, or the remote printer no longer exists, the function must wait for RPC
to time out and consequently fail the OpenPrinter call. This can take a while.
Passing a PRINTER_INFO_4 structure lets an application retrieve a bare minimum
of required information; if more detailed information is desired, a subsequent
EnumPrinter level 2 call can be made.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2004-07-23 14:01:33 UTC
Michael Lueck wrote:

| IIIFFFF you happen to do the PrintUI.DLL thing to attach
| those printers during the logon script, you get the slows.
| However thanks to a typo in my LOGON.BAT I was not getting
| my one time printer attachment so I clicked the button
| I leave in a utilities folder on the desktop for users
| to refresh their printers...  bing bing bing File/Print
| came right up. After I fixed the LOGON.BAT error, the
| slows came back.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:53:45 UTC