Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!CUNIXC.COLUMBIA.EDU!cck
From: cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim)
Newsgroups: comp.protocols.appletalk
Subject: Re: TOPs and KIP?
Message-ID: <8805201121.AA07033@columbia.edu>
Date: 20 May 88 11:22:08 GMT
References: <8805181532.AA00852@apatosaur.cis.ohio-state.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 85

>If you run the latest KIP (version 1/88) and the latest Kinetics
>K-Talk libraries you can have TOPS and CAP co-exist.  The Kinetics

Unless TOPS runs with a non-KIP "AppleTalk Bridge" acting as the
"portal" to the unix system (like AlisaTalk or PacerShare).  KIP 1/88
does not deal well with this situation (mainly due to the lack of
proper zone acquistion: adding this is non-trivial).  I don't think
that K-Talk uses the "portal" approach though.

>everyone is happy (well almost, we are having preformance problems
>that we are trying to track down).
If the problem in particular is with EtherTalk client/services seeming
to be slow, this is not suprising.  KIP 1/88 provides a basic level of
functionality in regards to EtherTalk, not necessarily performance.

Basically, the problem is that ethernet driver in the kbox cannot
always keep up with back-to-back packets.

With KIP 1/88, there are a number of paths through a KBOX running KIP:
*	LocalTalk -KIP-> LocalTalk
*	LocalTalk -KIP-> CAP/KIP
	LocalTalk -KIP-> EtherTalk
#	CAP/KIP -KIP-> EtherTalk
*#	CAP/KIP -KIP-> CAP/KIP
*#	CAP/KIP -KIP-> LocalTalk
#	EtherTalk -KIP-> LocalTalk
#	EtherTalk -KIP-> CAP/KIP
#	EtherTalk ->KIP-> EtherTalk (bridging two ethernets)
*'ed items existed in previous release of KIP as well.

The "#" marked items are all potential problems in that the "source"
can possibly send closely spaced back-to-back packets on the Ethernet
interface.

CAP/KIP -KIP-> LocalTalk was worked around by having the CAP host
reduce the number of back to back packets sent (generally to 1 packet
- e.g. so there were no back to back packets).  (attempting to modify
the spacing of packets on a unix system generally doesn't work very
well unless you work in very large time intervals O(1) second).  This
reduces throughput, but not as much as it would if we waited for
retries, etc that are generally specified in O(seconds).

CAP/KIP -KIP-> CAP/KIP and CAP/KIP -KIP-> EtherTalk can be "worked
around" much like CAP/KIP -KIP-> LocalTalk.

Now we are down to the last three major possible paths:
	EtherTalk -KIP-> LocalTalk
	EtherTalk -KIP-> CAP/KIP
	EtherTalk ->KIP-> EtherTalk (bridging two ethernets)
that are the most problematic.

The EtherTalk host may send quite a number of closely spaced
back-to-back packets to the kbox, of which, it is highly probable that
a number will be lost.  Reducing the probability of a back-to-back
packets by reducing the maximum packet return (generally the number of
packets sent in an atp response) as is done by CAP hosts would greatly
alleviate the situation, but one cannot expect ethertalk based
services/clients to do this.  With multiple EtherTalk hosts using
these routes, the situation will become even less pleasant.
Basically, if you have an EtherTalk client and a CAP or LocalTalk
server, you'll find that writes may be slower than if it were are
LocalTalk client and that reads will probably be acceptable (if it
were an EtherTalk server, then the same would hold for writes).  The
problem is exasberated by the relatively long atp retry intervals
(important for AppleShare) -- though making the retry too short would
probably cause a meltdown :-).

It is possible to modify the ethernet driver to handle tightly spaced
packets far better; however, it is not possible to do this without
killing off the localtalk service.  Currently, the driver has the
ethernet controller suspsending upon packet reception; setting it to
"resume" automatically instead of under the control of the cpu allows
one to keep up with packets better.  However, when this is done, there
is enough contention (for some resource: cpu, bus, memory, ?) that the
timing on outgoing localtalk sends is messed up (basically, it causes
the kbox to take too long in the middle of a packet and makes it look
like multiple packets).  [Actually, the contention is probably
bus/memory - the 82586 ethernet controller is effectively a small cpu
that accesses the bus/memory independently of the main cpu (68008) and
is probably fast enough to block out the 68008 long enough to mess up
the lap timing].

Charlie C. Kim
User Services
Columbia University