Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!vsi1!altnet!uunet!mcvax!ukc!strath-cs!glasgow!icdoc!qmc-cs!liam From: liam@cs.qmc.ac.uk (William Roberts) Newsgroups: comp.protocols.appletalk Subject: Re: Aufs and MacII ethernet card? Summary: EtherTalk is too fast for the Kinetics box Message-ID: <737@sequent.cs.qmc.ac.uk> Date: 10 Oct 88 16:21:20 GMT References: <677@accelerator.eng.ohio-state.edu> Reply-To: liam@cs.qmc.ac.uk (William Roberts) Organization: Computer Science Dept, Queen Mary College, University of London, UK. Lines: 85 Expires: Sender: Followup-To: Distribution: Keywords: In article morgan@JESSICA.STANFORD.EDU writes: > >.. but terrible performance from the MacII to >the Aufs machine. My guess (unconfirmed by traces or anything) is >that the MacII was blasting and overloading the Kbox, causing >retransmissions, whereas the Aufs machine is throttled down since it >expects to be talking to a Mac+ on a LocalTalk. We observed quite >good performance in both directions going thru a KFPS-4. Exactly right - the problem is that the KBox drops roughly alternate packets so if the flow quantum is large (i.e. >1) then the Mac->AUFS process goes like this (confirmed by traces): Time (secs) AUFS Server EtherTalk Mac 0 Send 8x512 bytes 0.1 chunk0 0.1 chunk1 (gets lost) 0.1 chunk2 0.1 chunk3 (gets lost) 0.1 chunk4 0.1 chunk5 (gets lost) 0.1 chunk6 0.1 chunk7 (gets lost) 5.0 Are you still there? 5.1 Yes I am 10.0 Are you still there? 10.1 Yes I am 15.0 Send missing chunks 1,3,5,7 15.1 chunk1 15.1 chunk3 (gets lost) 15.1 chunk5 15.1 chunk7 20.0 Are you still there? 20.1 Yes I am 25.0 Are you still there? 25.1 Yes I am 30.0 Send missing chunk 3 30.1 chunk3 30.2 Thank you 30.2 Send next 8x512 bytes and so on. This example takes 30 seconds to transfer 4k, less than 1200 baud! I discovered this when trying to work out why printing was so S...L....O....W from our whizzo MacIIs to our whizzo Sequent Balance. The 5 second status queries can't be used because they are not addressed to the same bit of the program (in fact, not even to the same program), so I am stuck with changing either a) The "flow quantum" which is the multiple of 512 that the receiver asks for, thus avoiding the lost packets and the timeouts b) The 15 second timeout (and put up with the dropped packets) I tried changing a) - after fixing the bugs in the CAP software, I discover that the Mac seems to insist on calling PAPWrite with 4k at a time. Unfortunately "if the data size is bigger than the flow quantum of the other end, the call will return with an error" so the stupid *@*#!* gives up. That only leaves changing b), but I haven't the time to do it now and it seems like the wrong solution anyway. I guess that the gateway loses packets just through lack of buffer space: my Sun code has no trouble seeing all of the packets involved. Anyone know how we send bug-reports to Apple themselves? (this is the fault of their Printer Manager stuff) -- William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu) Queen Mary College UUCP: liam@qmc-cs.UUCP LONDON, UK Tel: 01-975 5250