This is flow control. The computer and the printer have not made the proper arrangements so that the computer can know when to pause to let the printer catch up. You aren't likely to see this problem on parallel printers, though a bad cable can do this.
There are two choices for flow control: software or hardware. Software flow control is often referred to as XON or XON/XOFF, and you may see hardware flow control referred to as "ctsflow" or sometimes "dtrflow". Under high speed conditions, hardware flow control is preferred, but you do need to know HOW the printer should be wired to set this up, so software flow control is simpler.
The purpose of flow control is so that the printer can tell the computer that it is momentarily overwhelmed, cannot handle any more input right now, and the computer should suspend sending data until the printer notifies it that it is once again ready to receive data. If the computer and the printer do not agree on flow control, you will lose data. Whether or not the printer notifies you that this has happened is entirely up to the designer of the printer, so HP laser printers, for example. will display an error message on their front panel, but many other printers simply throw away data.
Most printers don't rely entirely on flow control. They usually also have a buffer that fills up with incoming data and gets emptied as it prints. If the buffer is larger than the print job, no flow control is necessarily needed. That's why small jobs print OK, but larger jobs may not- when the buffer fills, the printer needs to yell "Stop".
As the computer sending the data might not respond instantly to that request, the printer has a "high water mark" for the buffer. It might, for example, send the "Stop" signal when the buffer is 90% full. Some printers let you control that high-water mark. If yours does, setting it lower could help.
But by default, the Operating System provides NO flow control on a serial port. If nothing else has been done, a serial port will default to 9600 baud, 8 bit, no parity, and NO flow control.
The very first thing you want to do is DISABLE the serial port (example: "disable tty1a"). This may be confusing because you ENABLE a printer attached to a port, but you never, never want a printer port itself enabled for login. To be safe, check the upper case version of the port also ("disable tty1A").
Many intelligent serial ports (Digiboard, Equinox, Computone, Maxpeed) have ways to set and keep serial parameters on their ports. For example, if you have a Digiboard, you can type
"ditty /dev/ttyb02 9600 ixon printer"
to force the port to stay at 9600 with software flow control.
However, for the standard com ports (tty1a, tty2a), it's not as easy, and you need what's called a "hold-open" script.
The problem is that while intelligent serial boards have special commands to set flow control and keep it set, the standard Unix stty command doesn't work that way. To set any option, you have to "open" the port, which is simply done by combining the stty command with a redirection symbol:
stty ixon < /dev/tty1a
Technically, this command actually works, but the problem is
that the port will be reset to defaults
instant that the port is "closed", and that happens just
microseconds after you press return! So, effectively, it does
SCO technical articles suggest the following command:
( stty 9600 ixon -ixany ; while : ; do sleep 3600; done ) < /dev/tty1a &
The 9600 is the baud rate, and could be different, and of course your printer might be on a different port. You need to put this in a startup script so that it will run on each reboot.
Actually, nowadays there is no reason at all not to leave out the while and do:
(stty 9600 ixon ixoff -ixany; sleep 2000000000) < /dev/tty1a &
That's over 60 years of "sleep". There is an advantage to the "while" version: if the sleep gets killed, the other version will restart it.
It's also possible to control multiple printers with one shell; see Bela Lubkin's newsgroup post stty hold open scripts
Got something to add? Send me email.