jb@aries5.uucp (10/20/89)
In article <Added.YZCsgBO00Ui3Q7f085@andrew.cmu.edu> BSCHMIDT@bnr.ca (Ben Schmidt, B.T.) writes: >Stan Duten, c11234@d1.dartmouth.edu writes: >> PS. Many thanks to Jim Bruyn, Computer Systems Group, University of >> Waterloo for the ResEdit location of the Broadcast retry interval. > >can you share this information with info-appletalk? many thanks, >Ben Schmidt Information Systems/BNR Bitnet: bschmidt@bnr.ca Each chooser RDEV has a 'GNRL' resource #-4096 consisting of two bytes the first byte is the retry interval (timeout interval) and the second byte is the retry count. Note increasing the retry interval will increase the time that it will take to close the Chooser window. Maybe Stan Duten can give us some ideas of what timeout intervals and retry counts seem to work for him. You may wish to customize this for different speeds of lines. Somebody else asked a question about how to not have the checkboxes show up in the list of AppleShare volumes so that users cannot automatically select them for mount at boot time. The solution that I gave him was to modify the list rectangle. In PACK resource #-4096 change the following rectangles: 003b 0032 007b 0123 003a 0031 007c 0133 I tried 003b 0032 007b 00f3 003a 0031 007c 0103 Which seemed to hide the check boxes. The first rectangle is the list rectangle and the second is the frame rectangle. The check boxes are drawn by the AppleShare PACK resource. I did not have enough AppleShare volumes to know if this interfered with scrolling. Could somebody provide me with a recommended way for determing timeouts on a network. We have developed our own networking software for the Mac. My original thought was I can have 32 users waiting for the server to reply, the server can send back to each of these users 8 packets each taking app. 20 msec and the server needs app. 50 msec to process the request so I need a timeout of 32*(8*20+50) = 7 sec. However if there are errors this is very very slow for the users. Any suggestions? Thanks Jim Bruyn Computer Systems Group University of Waterloo
c11234@D1.DARTMOUTH.EDU (Stan Dunten) (10/24/89)
Van Jacobson (van@LBL-CSAM.ARPA) did some great work with stream (tcp) protocol timeouts. The copy I have came from Article 2361 of comp.protocols.tcp-ip. Basically he suggests measuring the average reply delay and it's variation then using a timeout of average+2*variation. When an reply comes in, the elapsed reply time, request->reply, is used in these equations: diff = reply time - ave ave = ave + diff/T1 dev = dev + (abs(diff)-dev)/T2 The timeout for later requests is ave+2*dev. He suggests a T1 of 8 and a T2 of 4. Also if a packet is lost (timeout goes off) he doubles the average. I have both modeled and used this. It works great. But this is for a stream protocol. The lumpiness of atp and the requirement to provide an 8 packet timeout are real pains. If atp ignored the callers time out time (what does he know) and computed its own by: Use the atp request -> first data packet time in the above equations to compute a timeout. Restart the timeout each time a good packet comes in. Your equation 32*(8*20+50) = 7 sec then becomes 32*(1*20+50) = 2.2 sec. My tracing of an AppleShare file transfer shows 16 short atp interactions plus those for the actual data. If most file transfers are less than 16 atp interactions (16*8*512 = 65K files) then most users will be doing short interactions. The Jacobson equations should react to this further reducing the 2.2 sec. Users scratching their heads will help still more. If you have software control of only one side of the atp interaction then: When making requests the preceding can be used. When responding to requests your software could: Only send 1 or 2 data packets even though more were requested. Setting the STS bit creates a 1 packet reply for use in the Jacobson equations. Early timeouts from the requesting end would be ignored. Disclaimer: We haven't tried any of the atp ideas. Good luck. all run spell*** "<*pass1"
tom@wcc.oz (Tom Evans) (10/24/89)
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: > (details on ATP timeout) What about when the TREL gets dropped? AppleShare (other AFP-compatibles as well) SHOULD KEEP GOING while they keep the packets stashed somewhere till the 30-second (CAP) TREL timer goes off. CAP just blocks - stonewalls till the 30 seconds is up. You see a 30-second hole in the universe. I don't know what AppleShare does, but it exhibits the same behaviour (with a 10-20 second hole). Maybe it runs out of memory for the buffers or something? I've had HyperCard take 5 minutes to launch (from CAP) on a bad net - all due to to the 30-second stalls. Does anyone know what AppleShare is really doing? Does it work better on a fat Mac II with lots of memory? --------- Tom Evans tom@wcc.oz | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby VIC 3179 Australia | approximation" Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway
ariza@srava.sra.JUNET (Michiharu Ariza) (10/25/89)
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: file: AppleShare, resource: FSMT, resource ID: 1801 (decimal) offset: 976 (hex), data: 30 3c 00 04 (hex) The offset may depend on the version of AppleShare. The integer 0004 is the multiplier in the formula. So changing it to 0008 should almost double the timeout interval. Michiharu (Michael) Ariza ariza@sra.co.jp SRA, Inc., Tokyo, Japan
andrews@Apple.COM (Richard Andrews) (10/26/89)
> What about when the TREL gets dropped? AppleShare (other > AFP-compatibles as well) SHOULD KEEP GOING while they keep the packets > stashed somewhere till the 30-second (CAP) TREL timer goes off. CAP > just blocks - stonewalls till the 30 seconds is up. You see a > 30-second hole in the universe. I don't know what AppleShare does, but > it exhibits the same behaviour (with a 10-20 second hole). Maybe it > runs out of memory for the buffers or something? > Does anyone know what AppleShare is really doing? Does it work better > on a fat Mac II with lots of memory? --------- I reluctantly admit to being one of the authors of AppleShare, but I haven't worked on it for over a year, so I won't be able to answer lots of questions. I wanted to at least address the question above. For each session, AppleShare, through ASP, queues up two ATP GetRequests. If the TREL gets lost on one of those, requests and responses will continue to flow on the session via the other GetRequest. If, while we're waiting for the 30-second timer to go off on one of these, the other TREL is lost, the session will hang until the first 30-second timer goes off. That's probably why you've seen a "10-20 second hole". I suspect that CAP only has one GetRequest per session, and that's why it blocks for a full 30 seconds each time a TREL is lost. That's what AppleShare is really doing. If you only lose one TREL at a time you will probably not notice anything. It shouldn't work any better on a fat Mac II with lots of memory, since it has nothing to do with memory.
jb@aries5.uucp (10/30/89)
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