Subject: Re: [netatalk-admins] pap problems - excessive retransmissions
From: Thomas Tornblom (Thomas.Tornblom@Hax.SE)
Date: Mon Aug 17 1998 - 12:44:24 EDT
I have noticed that some old LaserWriters (IIf, 630,...) gets confused when sent
large files and they forget to send status back that the printjob is done. This
makes pap hang around and eventually fails, which the printer spooler interprets
as a failure and that the job should be sent again.
Using the -E flag to pap workd around this by not waiting for the result from
the printer.
I see that at least one of your printers is a 630, and I definitely know that it
needs the -E flag to work properly.
> >Received: from terminator.rs.itd.umich.edu (terminator.rs.itd.umich.edu
[141.211.164.2]) by hellfire.englund.nu (8.8.8+Sun/8.8.8) with ESMTP id EAA10768
for <Thomas.Tornblom@Hax.SE>; Sun, 16 Aug 1998 04:24:59 +0200 (MET DST)
> From: Andras Kadinger <bandit@freeside.elte.hu>
> X-Accept-Language: hu,en,de
> MIME-Version: 1.0
> To: Netatalk list <netatalk-admins@umich.edu>
> Subject: [netatalk-admins] pap problems - excessive retransmissions
>
> Well, while we are discussing pap problems, let me present mine.
>
> I use a Linux 2.0.34 machine with netatalk-1.4b2+asun2.0a18.
>
> Sometimes pap hangs while/after sending a job; the job actually gets
> sent and all pages come out, but the connection does not get torn down.
> This, and some worse-than-expected performance observations led me to
> recompile pap with the debugging define enabled, and watch the results.
>
> All of this was conducted on an otherwise completely quiet, 10BaseT
> network; the largest 'distance' between any two nodes is two hubs and a
> router (Apple Network Server). The test file I sent consisted of the
> lines
>
> /buffer 255 string def
> { currentfile buffer readstring {pop} {exit} ifelse} loop
>
> (a 'while (fgets(buffer,256,stdin)!=NULL) ;' in PostScript) and about
> 2MB of \0s. This I hoped to be a good throughput testing (which was my
> goal originally).
>
> Here's what I found:
>
> Trying 10.253:128 ...
> OPEN >
> < OPENREPLY
> READ 1 >
> SENDSTATUS >
> < STATUS
> < TICKLE
> SENDSTATUS >
> < STATUS
> < READ
> DATA >
> SENDSTATUS >
> < STATUS
> | RETRANS
> SENDSTATUS >
> < STATUS
> < READ
> DATA >
> SENDSTATUS >
> < STATUS
> | RETRANS
> SENDSTATUS >
> < STATUS
> [... a lot of similar cycles...]
> < READ
> DATA >
> SENDSTATUS >
> < STATUS
> | RETRANS
> SENDSTATUS >
> < STATUS
> < READ
> DATA (eof) >
> | RETRANS
> SENDSTATUS >
> < STATUS
> < READ
> SENDSTATUS >
> < STATUS
> < DATA (eof)
> CLOSE >
> < CLOSEREPLY
>
> What I didn't think was appropriate (and I dare to say it constitutes a
> bug) is the excessive retransmission rate and the senseless double
> status updates; quite interestingly, the pattern didn't change when
> sending the job to papd on the same machine - I think this pretty much
> eliminates the possibility of network wire problems or faulty routers
> causing my problem.
>
> Real printers tried: Apple LaserWriter Pro 630, HP LaserJet 4MV, and a
> Harlequin RIP running on a 7300/200 under System 7.6.1 (with a
> reasonably recent OT). Same results every time.
>
> I tried to remove all status update parts from pap; great, now there
> were no status updates, but the retransmissions stayed intact :-), and
> performance (real-time) didn't increase much either.
>
> Looking into pap, I could not yet find any obvious reasons for this, so
> I'm starting to suspect the ATP stack routines - OTOH they are quite
> widely used I think, so I assume they should be well tested and bug
> free.
>
> Another possible culprit I'm afraid to have to came up with is the DDP
> protocol stack in the Linux kernel. Although if it was buggy or
> unreliable, I'd expect 1) to see all kinds of AppleTalk flakinesses
> (this is not the case) 2) many people observing and reporting 1) (which
> is also not the case AFAIK).
>
> People with a couple of minutes spare time, please compile a pap with
> #EBUG, and report Your observations. I want to fix pap (unless this
> problem only appears here) so that I can go on to fix papd, so that I
> can go further on and implement an OPI framework upon them.
>
> Les, You volunteered for testing - I think, I could definitely benefit
> from Your help now.
>
> Thank You in advance,
>
> Sincerely,
> Andras Kadinger
> bandit@freeside.elte.hu
>
Real life: Thomas Törnblom Email: Thomas.Tornblom@Hax.SE
Snail mail: HB Hax Phone: +46 18 290 290
Banvallsvägen 14 Fax: +46 18 290 291
S - 754 40 Uppsala, Sweden Cellular: +46 73 986 6318
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:08 EST