Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!wcc!tom From: tom@wcc.oz (Tom Evans) Newsgroups: comp.protocols.appletalk Subject: Re: Shiva NetSerial Review Message-ID: <534@wcc.oz> Date: 20 Dec 89 03:33:09 GMT References: <1005@maytag.waterloo.edu> <3074@umn-d-ub.D.UMN.EDU> <1861@gazette.bcm.tmc.edu> Organization: Webster Computer, Melbourne, Australia Lines: 77 In article <1861@gazette.bcm.tmc.edu>, klong@wilkins.bcm.tmc.edu (Kevin Long) writes: > Our experience with the NetSerial has been mixed, and I'd like to ask if > anyone else has the problems we've had. > People can call up from home and print small files to printers, etc, with > no problem. But if we equip the home machine with TOPS and try to mount > a volume at the office or use ncsa telnet to pull a file off of one of > our unix hosts gatewayed through the office network's fastpath, the > connection is inevitably dropped, sometimes after 5 minutes, sometimes > after 10. I've had people with similar problems with other serial link hardware and software, specifically running one of the electronic mail packages. They find that short messages are fine, but long ones die. How long is long? About 2000 characters or so. The following from 2 months ago gives a good explanation of a possible reason: Note that this addresses AppleShare, but applies to all programs that use AppleTalk's Transaction Protocol (ATP) - this is most of them. Note (for explanation) that a BIG data request on ATP looks like: Req. Device: [Request] Rsp. Device: [RSP1] [RSP2] [3] [4] [5] [6] [7] [8] so there are from 1 to 8 response packets (568 bytes each). This depends on how much data was asked for. Anyway, the article: > Date: 17 Oct 89 03:32:00 GMT > Sender: daemon@ucbvax.BERKELEY.EDU > Organization: The Internet > Lines: 28 Does anyone have a fix for this piece of Apple stupidity? Externally it appears that the AppleShare code uses the following retransmission scheme: During the server signon the user MAC sends a full size echo packet and records the elapsed time until the reply. This time is then 2 times the one way packet time. It doubles this and uses that as the ATP timeout time. It is now 4 times the one way packet time. It then sends an 8 packet ATP request with a 4 packet time timeout. Guess what happens. While the 5th packet is coming in it asks for a resend of the last 4 packets. Now things really go to H... in a Handbasket. It uses the first copy of the last 4 packets and requests the next group of 8. Those 8 end up behind the second copy of the last 4 packets. Timeout, Timeout, Timeout ... We informed Apple of this problem over two years ago. To err is human but not to be able fix one's mistakes is stupidity. Does anyone know where the 2 is that is used for the doubling? I would like to change to about 8. PS. Many thanks to Jim Bruyn, Computer Systems Group, University of Waterloo for the ResEdit location of the Broadcast retry interval. --------- Other articles that followed this said where the "2" is and how to patch it. Do Shiva give you in INIT or something to drop in your System folder to patch these numbers for you? --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby, Melbourne 3179 | approximation" Victoria, Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832