Folks --
My problem has finally been solved. It was prestty obscure, and information I
found out along the way may or may not be useful information. I pass it along
for your enlightenment.
I want to thank all who responded, but the suggestions made did not go towards
solving this problem.
The problem was:
>>
> THIS IS A REPOST!!!
>
> I haven't received a suggestion that worked and I am up against it!
>
> *********************************
>
> The problem I'm having is a error that pops up on an LX system running 4.1.3c.
> This system serves a print server for a QMS networked printer, and has 7 other
> SUns IPCs and LXs (4.1.3 & 4.1.3c, respectively), as well as 5 PCs using
> FTP PC/TCP 2.3. Printing Sun to Sun is okay, but PC to Sun is the problem.
>
> The PC users print very large Postscript files (Harvard Graphics) of up
> to 20 MB. The Sun to Sun traffic is almost always 3 MB or smaller. When trying
> to print a 20 MB file to the Sun LX print server from the PC, we get
>
> lpd: Lost connection
>
> My best guess as to what is happening is the the PC is not responding to the
> ACKs fast enough from the Sun, and the Sun drops the connection. But this is
> only a guess. There is nothing in Answerbook, SunSolve, or man pages to
> describe this error.
>
> Things I know are:
>
> *there is a "lpr" patch, but it doesn't mention my problem, so I haven't
> *installed is yet.
> *
> *Network traffic hovers between 15% and 20%
> *
> *I know that I could send these jobs to the QMS directly, but that doesn't
> *work, either. At least I get an error log on the Sun.
> *
> *If I ftp the file to the Sun, it prints without a problem.
> *
> *FTP had no suggestions that worked.
> *
> *I tried to hack the TCP_KEEP_IDLE multiplier to 360*60*PR SLOWER, but with no
> *change.
>
> Any suggestions you all might have would be greatly appreciated.
THe solution has many steps. First, this is what DID NOT work:
1) FTP really does have a patch to 2.3. It was developed to fix problems
notices in network print server boxes with small buffers such as
lantronics. It basically slos down the transmission rate from the PC
to the print server (the Sun in this case). It had no effect on my
problem, however.
2) Sun's lpr/lpd patch had no effect. hacking timoeout numbers for the
kernel had no effect, either.
What DID WORK was:
1) the QMS printer's default memory partitioning was not optimal for HUGE
graphics jobs. I won't get into details, but if you would like a
status page, let me know. It contains all the needed memory info.
There memory allocation is not dynamic - all
2) QMS has newer, better Windows 3.1 drivers for their printers. They are
avaialble to their maintenance customers via anon ftp from their server.
They helped a lot.
3) In the Windows printer setup, there is a an option to clear memory
after each page is sent ( the actual verbage of the choice varies with
the PS printer driver you are using). THis MUST be selected, because QMS
stores all previous pages in memory if you don't. It eventally fills
the buffer and dies.
4) There are to types if postscript - asii and binary. I didn't know
there wwas a binary form until I worked on this problem. It is an
optional setting on many printers, including QMS. In this case,
you can select the "PS Binary" option, which prints both ascii and
binary.
We still get the occasional timeout error, but it now prints everything. So,
I croos my fingers and say it's finally fixed.
Thanks again for everyone's response. And if you ever call QMS for support,
Hanks Shavers is a VERY knowledgable and helpful support rep.
Charles Mengel
LGI
Columbia, MD
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:09 CDT