Path: utzoo!attcan!utgpu!watmath!maytag!aries5!jb
From: jb@aries5.uucp
Newsgroups: comp.protocols.appletalk
Subject: Re: ATP timeouts
Message-ID: <708@maytag.waterloo.edu>
Date: 30 Oct 89 12:54:31 GMT
References: <8910170031.AA15296@dartvax.dartmouth.edu> <2954@srava.sra.JUNET>
Sender: daemon@maytag.waterloo.edu
Reply-To: jb@aries5.UUCP ()
Organization: Computer Systems Group, University of Waterloo
Lines: 33

In article <2954@srava.sra.JUNET> ariza@srava.junet (Michiharu Ariza) writes:
>In article <8910170031.AA15296@dartvax.dartmouth.edu> c11234@D1.DARTMOUTH.EDU (Stan Dunten) writes:
>>Does anyone have a fix for this piece of Apple stupidity?
>>
>>Externally it appears that the AppleShare code uses the following
>>retransmission scheme:
>
>From curiosity I poked around in AppleShare resources and found the code
>that calculates the timeout. The code uses the following formula:
>
>    timeout = max(2, (tick_difference * 4 + 60) / 60)
>
>where tick_difference is the difference of tick counts before and after of
>an echo DDPWrite.  This code is located at:
>
One little glitch with this.  First AppleShare does the DDPWrite, and
then waits for the echo to be received.  Therefore All that they are
measuring is:
   time to receive a packet +
   time for packet to travel across any bridges etc.

They are not measuring the time to transmit the packet.  Hence the
behaivour (stupidity) that Stan observed - namely that the time out
was only the time to receive 4 packets instead of 8.  The only patch
to this is to change the multiplier to 8.   

However ideally AppleShare should obtain Ticks BEFORE doing the DDPWrite
instead of after.

Jim Bruyn
Computer Systems Group
University of Waterloo
AppleLink D0365