If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):
Slow parallel port printing:
What you probably have is a hardware problem. Your parallel port isn't functioning correctly; specifically it isn't generating interrupts when it should, and this causes the SCO driver to run slower. SCO does, in fact "acknowledge" this, much in the same way that you would acknowledge that an accident between two other vehicles caused a traffic jam that caused you to be late for work because you had to take back roads to avoid the mess.
If you got to http://www.sco.com/ta and type in "slow parallel", you'll get 20 or so hits related to this issue, but you'll also see that none of them are particularly recent, and most basically say what I've said in the first paragraph.
"man parallel" on your own system explains how to monitor parallel port activity with "crash" and what you can do if you can't fix the hardware (which is what you probably should do).
In most situations, I replace direct parallel port printers with print servers.

/Bofcusm/74.html copyright 1997-2004 (various authors) All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
"In most situations, I replace direct parallel port printers with print servers."
Given that reliable parallel port operation limits one to a cable length of no more than 15 feet, network print servers make a lot more sense.
Incidentally, a seemingly slow parallel port can be a victim of an overly long cable -- this malady can also affect network print servers that drive their printers via a parallel port. To understand why, you need to know a little bit about how the Centronics interface operates.
Centronics' original design consisted of eight data lines corresponding to the eight bits of a byte (usually labeled D0-D7) and two handshaking lines called *STROBE and *ACK (the asterisk indicates that these lines are low-true). Other lines, such as *BUSY and *RESET, exist in modern implementations to increase functionality. However, only D0-D7, *STROBE and *ACK are required to set up a working interface.
When the port is quiescent and the printer idle, D0-D7 will be at random logic levels. *STROBE, which is controlled by the computer, will be held at logic one (high or 5 volts) and *ACK (acknowledge), which is controlled by the printer, will also be held high.
When the computer is ready to print it will place a data byte on D0-D7, with the hardware logic corresponding to the individual bit values (i.e., a set bit will be manifested by the corresponding data line being brought high and a clear bit represented by a logic zero-- low or zero volts -- on the corresponding line. Following a small delay of one to two microseconds, the computer will inform the printer that a valid byte is present by momentarily bringing *STROBE low and then returning it to high -- *STROBE is said to have been toggled. Each transition of *STROBE must be maintained for at least one microsecond to assure that the printer will have sufficient time to recognize the toggling of *STROBE.
Assuming that the printer is ready for data, it will react to the toggling of *STROBE by reading the data from D0-D7. When the printer has completed this process it will toggle *ACK, which (in most cases) will cause an interrupt to occur in the computer, letting it know that the printer is ready for more data. Here again, each transition on *ACK must be maintained for at least one microsecond.
Now, in examining the above sequence it becomes clear that the data transfer rate can be quite high (as much as 500 K per second, with an effective signaling rate of 1 MHz) and that there isn't much time for the data signals to propagate. Tehoretically, electrical impulses can travel about 328 yards per microsecond. However, reactive effects within the cable substantially reduce the rate of propagation. If the cable is too long, errors will occur, either resulting in slower printing, random garbage appearing in the printer's output, or both.
Also, the waveform of the various signals must be reasonably rectangular (as seen on an oscilloscope) so that the logic transitions are clearly defined. If the waveform is excessively distorted, which can occur with a long cable, the hardware may have difficulty in determining when a logic transition has occurred, again causing errors.
Where the biggest slowdown comes is in the receipt of the *ACK signal. If signal distortion and/or propagation delay occurs, the expected interrupt from *ACK will not arrive as often, which means the computer will not feed data to the port as often. If the cable is too long, *ACK may become too distorted to cause a clean logic transition and the expected interrupt may never occur, stalling the printer.
The bottom line is keep the cable short, 10 feet or less is ideal. At 20 feet, printing problems will start to occur. Your only solutions if you need to increase the distance between the computer and the printer are to either use an EIA-232 (RS-232) interface, which can operate over distances of several hundred feet, or a network print server (a 100Base-T network is reliable out to 100 meters or about 328 feet).
--BigDumbDinosaur
"In most situations, I replace direct parallel port printers with print servers."
Given that reliable parallel port operation limits one to a cable length of no more than 15 feet, network print servers make a lot more sense.
Incidentally, a seemingly slow parallel port can be a victim of an overly long cable -- this malady can also affect network print servers that drive their printers via a parallel port. To understand why, you need to know a little bit about how the Centronics interface operates.
Centronics' original design consisted of eight data lines corresponding to the eight bits of a byte (usually labeled D0-D7) and two handshaking lines called *STROBE and *ACK (the asterisk indicates that these lines are low-true). Other lines, such as *BUSY and *RESET, exist in modern implementations to increase functionality. However, only D0-D7, *STROBE and *ACK are required to set up a working interface.
When the port is quiescent and the printer idle, D0-D7 will be at random logic levels. *STROBE, which is controlled by the computer, will be held at logic one (high or 5 volts) and *ACK (acknowledge), which is controlled by the printer, will also be held high.
When the computer is ready to print it will place a data byte on D0-D7, with the hardware logic corresponding to the individual bit values (i.e., a set bit will be manifested by the corresponding data line being brought high and a clear bit represented by a logic zero -- low or zero volts -- on the corresponding line. Following a small delay of one to two microseconds, the computer will inform the printer that a valid byte is present by momentarily bringing *STROBE low and then returning it to high -- *STROBE is said to have been toggled. Each transition of *STROBE must be maintained for at least one microsecond to assure that the printer will have sufficient time to recognize the toggling of *STROBE.
Assuming that the printer is ready for data, it will react to the toggling of *STROBE by reading the data from D0-D7. When the printer has completed this process it will toggle *ACK, which (in most cases) will cause an interrupt to occur in the computer, letting it know that the printer is ready for more data. Here again, each transition on *ACK must be maintained for at least one microsecond.
Now, in examining the above sequence it becomes clear that the data transfer rate can be quite high (as much as 500 K per second), which means there isn't a lot time for the data signals to propagate. Theoretically, electrical impulses can travel about 328 yards per microsecond. However, reactive effects within the cable substantially reduce the rate of propagation and also distort the signal's waveform or shape. If the cable is too long, errors will occur, either resulting in slower printing, random garbage appearing in the printer's output, or both.
To assure reliable operation, the waveform of the various signals must be reasonably rectangular (as seen on an oscilloscope) so that the logic transitions are clearly defined. If the waveform is excessively distorted, which can occur with a long cable, the hardware may have difficulty in determining when a logic transition has occurred, again causing errors.
Where the biggest slowdown comes is in the receipt of the *ACK signal. If signal distortion and/or propagation delay occurs, the expected interrupt from *ACK will not arrive as often, which means the computer will not feed data to the port as often. If the cable is too long, *ACK may become too distorted to cause a clean logic transition and the expected interrupt may never occur, stalling the printer.
The bottom line is keep the cable short, 10 feet or less is ideal. At 20 feet, printing problems will start to occur. Your only solutions if you need to increase the distance between the computer and the printer are to either use an EIA-232 (RS-232) interface, which can operate over distances of several hundred feet, or a network print server (a 100Base-T network is reliable out to 100 meters or about 328 feet).
--BigDumbDinosaur
"In most situations, I replace direct parallel port printers with print servers."
Given that reliable parallel port operation limits one to a cable length of no more than 15 feet, network print servers make a lot more sense.
Incidentally, a seemingly slow parallel port can be a victim of an overly long cable -- this malady can also affect network print servers that drive their printers via a parallel port. To understand why, you need to know a little bit about how the Centronics interface operates.
Centronics' original design consisted of eight data lines corresponding to the eight bits of a byte (usually labeled D0-D7) and two handshaking lines called *STROBE and *ACK (the asterisk indicates that these lines are low-true). Other lines, such as *BUSY and *RESET, exist in modern implementations to increase functionality. However, only D0-D7, *STROBE and *ACK are required to set up a working interface.
When the port is quiescent and the printer idle, D0-D7 will be at random logic levels. *STROBE, which is controlled by the computer, will be held at logic one (high or 5 volts) and *ACK (acknowledge), which is controlled by the printer, will also be held high.
When the computer is ready to print it will place a data byte on D0-D7, with the hardware logic corresponding to the individual bit values (i.e., a set bit will be manifested by the corresponding data line being brought high and a clear bit represented by a logic zero -- low or zero volts -- on the corresponding line. Following a small delay of one to two microseconds, the computer will inform the printer that a valid byte is present by momentarily bringing *STROBE low and then returning it to high -- *STROBE is said to have been toggled. Each transition of *STROBE must be maintained for at least one microsecond to assure that the printer will have sufficient time to recognize the toggling of *STROBE.
Assuming that the printer is ready for data, it will react to the toggling of *STROBE by reading the data from D0-D7. When the printer has completed this process it will toggle *ACK, which (in most cases) will cause an interrupt to occur in the computer, letting it know that the printer is ready for more data. Here again, each transition on *ACK must be maintained for at least one microsecond.
Now, in examining the above sequence it becomes clear that the data transfer rate can be quite high (as much as 500 K per second), which means there isn't a lot time for the data signals to propagate. Theoretically, electrical impulses can travel about 328 yards per microsecond. However, reactive effects within the cable substantially reduce the rate of propagation and also distort the signal's waveform or shape. If the cable is too long, errors will occur, either resulting in slower printing, random garbage appearing in the printer's output, or both.
To assure reliable operation, the waveform of the various signals must be reasonably rectangular (as seen on an oscilloscope) so that the logic transitions are clearly defined. If the waveform is excessively distorted, which can occur with a long cable, the hardware may have difficulty in determining when a logic transition has occurred, again causing errors.
Where the biggest slowdown comes is in the receipt of the *ACK signal. If signal distortion and/or propagation delay occurs, the expected interrupt from *ACK will not arrive as often, which means the computer will not feed data to the port as often. If the cable is too long, *ACK may become too distorted to cause a clean logic transition and the expected interrupt may never occur, stalling the printer.
The bottom line is keep the cable short, 10 feet or less is ideal. At 20 feet, printing problems will start to occur. Your only solutions if you need to increase the distance between the computer and the printer are to either use an EIA-232 (RS-232) interface, which can operate over distances of several hundred feet, or a network print server (a 100Base-T network is reliable out to 100 meters or about 328 feet). Given the greater flexibility of networking, you'd be better off going that route.
--BigDumbDinosaur
BigDumbDinosaur made a comment on this at http://aplawrence.com/Blog/1007.html
---July 22, 2004
---July 22, 2004
---July 22, 2004
---July 22, 2004
Wed Aug 3 20:20:45 2005: Subject: Gantry
If you are using Printek dot matrix printers and experience slow LPT port printing, try setting Minimum Buffer: No in the Parallel Interface menu. Worked for me today on a FormsPro 4503se in OpenServer 5.0.4 on LPT1 (/dev/lp0)
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar