smiller@umn-cs.cs.umn.edu (Steven M. Miller) (05/16/88)
I'm currently running TOPs with a Sun as a fileserver with the Kinetics gateway code. I recently tried to use KIP but TOPs did not function. Look worked form the Sun side and I could telnet from the Mac's to the Sun with the KIP code in place. Is there anyone who has this configuration working? Is there some key parameter that needs changing in /etc/atalkatab? Or something in prompt.config? Thanks for any help you can provide. By the way the KIP code is the 1/88 version. -Steve smiller@umn-cs.cs.umn.edu -- -Steve Miller, U of MN
evan@ndcheg.UUCP (Evan Bauman) (05/18/88)
In article <5407@umn-cs.cs.umn.edu>, smiller@umn-cs.cs.umn.edu (Steven M. Miller) writes: > I'm currently running TOPs with a Sun as a fileserver with the Kinetics > gateway code. I recently tried to use KIP but TOPs did not function. > Look worked form the Sun side and I could telnet from the Mac's to the Sun > with the KIP code in place. > As I understand it, CAP requires the KIP code and Tops requires the Kinetics gateway code. The two will not co-exist on the same K-box. Also, Kinetics' K-spool software will not work with the KIP code. NCSA Telnet works with either code. Evan Bauman University of Notre Dame ..!iuvax!ndcheg!evan evan@ndcheg.cheg.nd.edu <-------(any day now!) -- --------------------------------------------------------------------------- This message has been sponsored by Powdermilk Biscuits in the big blue box. ---------------------------------------------------------------------------
verber@APATOSAUR.CIS.OHIO-STATE.EDU (Mark Verber) (05/18/88)
Date: 17 May 88 18:49:19 GMT From: ndcheg!evan@iuvax.cs.indiana.edu (Evan Bauman) Organization: Univ. of Notre Dame Subject: Re: TOPs and KIP? References: <5407@umn-cs.cs.umn.edu> Sender: info-appletalk-request@andrew.cmu.edu To: info-appletalk@andrew.cmu.edu 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 libraries talk EtherTalk now (rather than the older Ethernet DDP). The latest KIP gateway will do either DDP in IP or EtherTalk. Hense everyone is happy (well almost, we are having preformance problems that we are trying to track down). ---------------------------------------------------------------------- Mark A. Verber MaBell: 614-292-7344 Computer Science Department MX: verber@cis.ohio-state.edu Ohio State University DUMB: verber@ohio-state.arpa 2036 Neil Ave, Columbus, Ohio 43210 UUCP: ..!att!osu-cis!verber
mday@cgl.ucsf.edu (Mark Day) (05/19/88)
In article <562@ndcheg.UUCP> evan@ndcheg.UUCP (Evan Bauman) writes: > Also, Kinetics' K-spool software will not work >with the KIP code. > I'm still a little confused about what is needed to print from a Mac II with a Kinetics EtherPort II card to a LaserWriter that is connected to a UNIX box via its serial port. I understand that K-spool will do what I want, but from what I have heard, it involves modifying the kernel. Is this true? Is there a better (and cheaper) solution to sharing LaserWriters between UNIX machines and Macs on the ethernet? Thanks in advance, ---------- Mark Day UUCP: ..ucbvax!ucsfcgl!mday ARPA: mday@cgl.ucsf.edu BITNET: mday@ucsfcgl.BITNET
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (05/20/88)
>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
elwell@saqqara.cis.ohio-state.edu (Clayton Elwell) (05/23/88)
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) writes:
[good analysis of the EtherTalk choking problem in KIP 1/88]
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.
I'd change that to "it is not EASY to do this ...". The Kinetics
EtherTalk gateway code does not seem to have this problem. The
handling of the Ethernet controller in the KIP gateway is pretty
elementary, from my reading of the source. Also, this isn't all
that's happening. We are seeing a repeatable 50% packet loss through
*either* IP or EtherTalk, if the EtherTalk option is turned on. If it
is not turned on, performance goes back up to normal...
[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].
I haven't looked at the code that talks to the SCC, but it might be
possible to get it to do more of the work. In any case, I'd suggest
talking to Kinetics to see if they are willing to "share their
secrets," as it were :-). If the new KIP actually allowed usable
performance on EtherTalk, life would be pretty cool.
-=-
Clayton M. Elwell <elwell@tut.cis.ohio-state.edu>
-=-
"Gee, the Captain's vanished utterly so we'd better beam down the second-in-
command to exactly the same coordinates to see what happened to him!"