Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.appletalk Subject: Re: Rutgers CAP/NeXT and DECstation changes... Message-ID: Date: 13 Nov 90 06:37:10 GMT References: <9011021552.AA23198@aquarium.ecn.purdue.edu> <1990Nov9.211533.10511@mathrt0.math.chalmers.se> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 25 I can't comment on the problems with UAB. I don't use it. But as for the problems with native Ethertalk on a Sparcstation, we may have some help coming. There will be a new release of Rutgers CAP shortly. There are some inelegancies in the way it handles ARP that didn't affect our major applications but do cause some problems: atlook generally fails the first time. If you have lots of appletlak bridges on the network, atlook can fail up to the number of times you have bridges macdump generally fails the first time, and may break the connection during use I haven't observed any problems with aufs. Dropped packets as shown by etherstat are hard to be sure about. Normally they indicate packets sent to a port that doesn't have anybody listening on it. I wouldn't expect them to indicate a problem with aufs. At one point I had problems due to insufficient input buffer sizes, but that should not be present in ru-cap2. There are some parameters for aufs controlling maximum packets sent at once. Could you be overloading the KFPS 4? Try running aufs with -S 1 -R 1. As for the new version, I'm trying to test the new version long enough to see if there are any more subtle problems. So far it looks pretty solid.