Subject: [netatalk-admins] pap problems - excessive retransmissions

From: Andras Kadinger <[email-masked]>
Date: Sun, 16 Aug 1998 04:16:46 +0200

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
[email-masked]

---

From: Thomas Tornblom <[email-masked]>
Date: Mon, 17 Aug 1998 18:44:24 +0200 (MET DST)

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 <[email-masked]>; Sun, 16 Aug 1998 04:24:59 +0200 (MET DST)
> From: Andras Kadinger <[email-masked]>
> X-Accept-Language: hu,en,de
> MIME-Version: 1.0
> To: Netatalk list <[email-masked]>
> Subject: [netatalk-admins] pap problems - excessive retransmissions
> 

Real life:      Thomas Törnblom             Email:  [email-masked]
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