I don't find anything suitable on this topic: we have a Solaris server, running CSW CUPS and several network printers. Printing using LPD is fast, but when we try socket or SMB, it is painfully slow (<1 sec vs. 30 seconds for a small job).

We avoided this by using LPD up until now when there is a printserver that only supports socket and SMB. The customer declines to replace the unit (please don't ask - we tried everything).

And on the other hand why would socket be slower than LPD?? Has anyone any ideas what to look for/into?

Many thanks!

3 Answers 3


I'm a bit late to the party, I know.
This may be solved by setting waiteof=false


CUPS by default waits for the printer to be ready before sending new print jobs as a safety net. This causes it to be slow as it waits for what is being printed to finish.

Also make sure to update to 1.4.4. Supposedly fixed.

You will want to install a version more recent than 1.4.4. Cups packages for major distros still have this bug.
Eg: Debian Squeeze (current stable as of 2012), has cups 1.4.4-7, but this bug is still present. I had to install cups 1.5.3 from sid (unstable) to fix this issue.


Things to try:

  1. Try trussing the process and see which syscalls appear to be slow.
  2. Try snooping the network traffic when it's via SMB.
  3. Increase the log verbosity in cupsd.conf (/etc/opt/csw/cups/cupsd.log if you're using the latest version of the package) and read the logs (/var/opt/csw/log/cups/...)
  4. Check which version of the CUPS you're using, and who provides it (is it Blastwave or OpenCSW?)
  5. Ask on an IRC channel, if you're using an OpenCSW package, there's #opencsw on Freenode

Will changing the network/speed or duplex at any point on your network help?

Most network cards are on auto negotiate by default. I'm wondering if forcing the link speed and duplex to whatever your network runs at will help.

I'm guessing that the 'spool file' is much larger and therefore more data to send over the network when using SMB. You'll need to use a network sniffer to verify this.

  • No, the network is good. The jobs are maybe 2MB/piece. I suspect some kind of handshake or badly implemented in-printer part.
    – slovon
    Feb 16, 2010 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .