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
P.S. Bugzilla did not appreciate three seconds worth of logs... I will upload to
a URL and paste that into the URL field...
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.
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.
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
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.
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.
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.