Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ANDREW.CMU.EDU!tjh+ From: tjh+@ANDREW.CMU.EDU (Tom Holodnik) Newsgroups: comp.protocols.appletalk Subject: Re: idle bug? Message-ID: Date: 1 Sep 89 14:20:09 GMT References: <2394@bingvaxu.cc.binghamton.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 31 Matt- I saw the same symptoms you're seeing. What we did to correct the situation was to upgrade the FastPath-2 to a FastPath-4 (the FastPath-4 has better performance), and to break up the network into two segments served by two Kinetics gateways. It's been some time since we dealt with this, and I hesitate to give you anything less than the correct answer. The best way for you to determine what is happenning is to turn on the various levels of protocol debugging (esp. ATP) within CAP, when you call the papif filter. I saw that ATP transaction release packets weren't being received at the spooler, and that the socket on the laserwriter had been closed. My guess was that the PAP tickle timer had expired, and the laserwriter closed the connection. I saw those symptoms during times when the network was heavily stressed (typically between 10am and 4pm), while printing was fully reliable during off peak hours. Making the PAP flow quantum smaller made the problem worse, since more ATP control (TrReq, TrResp, and TrRel) packets were required for the same amount of data. Since the probability of dropping packets is equal for all packets, the fewer packets sent the better. The real trouble was that we were dropping packets, not just control packets. I thought the trouble wasn't that there was anything wrong with the hardware of the software, but that something was misconfigured and outside of the proper specification. If there are other services on your network that are suffering, you should consider them, also. That was why we scaled back the size of our network. Hope this helps, Tom