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. TIA! Michael 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.
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 parallel) 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. Thanks Michael
Michael, 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.
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) ? from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_9fjn.asp 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.
closing