Subject: [netatalk-admins] pap problems - excessive retransmissions
From: Andras Kadinger (bandit@freeside.elte.hu)
Date: Sat Aug 15 1998 - 22:16:46 EDT
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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:05 EST