Waitings in the PS.

[Andres Abello]

Hi everyone,

I've been having problems with a Print System, sometimes it gets very slow and the waiting request start to pile up sometimes 300% more than the usual rate.

So my question is, what could be causing this?

thanks in advance.

[Andres Abello]

I discovered de following..

first I'm getting a lot of the following messages:

10:48:34 920 (FROM XXXXXX ):MSRMLSDISP0:DISPLAY:Unable to connect to XXXXXX in 120 secs.
10:48:47 920 (FROM XXXXXX ):MSRDISP14:DISPLAY:LPR connection to XXXXXX rejected: 1 .
10:49:05 920 (FROM XXXXXX ):MSRDISP14:DISPLAY:LPR connection to XXXXXX rejected: 1 .
10:46:16 920 (FROM XXXXXX ):MSRDISP14:DISPLAY:LPR connection to XXXXXX rejected: 1 .


and also the printer/worker is consuming a lot of mips printing to virtual devices...

[Paul Kimpel]

It's obvious from your second message that the MCP Print System is
having trouble connecting to the LPR client. If the Print System cannot
connect, then the print request stays at the top of the queue for that
destination device, and any further print requests for that device will
queue behind it. If it takes many retries until a connection is
established, then that could explain why the requests are piling up at a
much higher rate.

I assume that the Print System is connecting to the LPR client by means
of TCPPRTSUPPORT. In that case, it is TCPPRTSUPPORT this is making the
connection to the client, not the Print System directly.

This sounds to me like you have a networking problem, or perhaps a
problem with the LPR client. Another possibility is that the client is
busy with a print request from another system and cannot accept a
connection from the MCP until that request is finished.

* What value do you have configured for PRINTER_EXCEPTION_STATUS in
the SYSTEM/TCPPRTSUPPORT/CONFIG file?

* What value for TIMEOUT?

* Are you seeing this problem on all (or most) of your printers or
just a few of them?

* Are they all LPR printers, or do you see the problem with other
protocols?

As to the high MIPS usage, a part of that may be due to the problems
with connecting to the LPR client and the overhead of retrying multiple
times.

A larger part, however, is that LPR is not a particularly efficient
protocol. TCPPRTSUPPORT must deal with each printer file in the request
in two phases. In the first phase, it must parse the print lines and
calculate the length of the file as it will be sent to the LPR client.
This is because format of the data sent to LPR is considerably different
from the MCP printer-backup file format, and LPR requires the data to be
prefixed with a byte count for the data stream. In the second phase,
TCPPRTSUPPORT sends the byte count, followed by the converted data stream.

I'm not sure about this, but it's possible that TCPPRTSUPPORT must do
this two-pass conversion each time it tries to connect, so if the
connection fails, the processor time spent doing the conversion is wasted.

Another limitation of LPR is that the source TCP port (the one used by
TCPPRTSUPPORT) must be in the range 721 through 731; thus there are only
11 possible source ports, and thus only 11 LPR jobs can be in process at
once. If you have a lot of LPR printers, then it is possible that
printing could be throttled by the number of available source ports.

I would not recommend LPR for high-volume printing if any other options
are available. I would use it only when the remote client does not
support any of the other protocols available in the MCP. Direct TCP/IP
printing over port 9100 (sometimes called a "RAW" or "JetDirect" port)
is almost universally available in network-capable printers. Another
good option is SMB/CIFS printing (i.e., Windows "shared printers", also
available through SAMBA for Unix/Linux systems).

Another option to consider, especially if you are concerned about
processor overhead on the MCP side, would be to have the MCP send the
print requests to an external print server (e.g., a Windows or
Unix/Linux server), and have that external server deal with the overhead
of the LPR protocol.

Enterprise Output Manager (EOM, DEPCON) running on an external Windows
server can also send to LPR printers, and would be another excellent
choice.

One final point: I try to avoid sending print data directly from the MCP
to printers that are also directly connected from other systems.
Generally, networked printers can only accept one incoming connection at
a time, so if the printer is busy with a request from some other system
when the MCP tries to connect, the connection will fail and the MCP will
need to retry its request later. It is better in these cases to
configure a print server between the MCP and the networked printer, as
the print server is designed to accept many incoming requests at a time,
spool the incoming print data, and then spool that data out as the
printer becomes available.

Note that many high-end copier/printer/scanner document processors have
internal disks, can accept multiple incoming connections at a time, and
effectively serve as their own print server, so this consideration does
not necessarily apply to them. Most desktop printers can only accept one
connection at a time, however, and for those using an intermediary print
server is a good idea.

--
Paul