Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!monet.Berkeley.EDU!kre
From: kre@monet.Berkeley.EDU.UUCP
Newsgroups: comp.protocols.appletalk
Subject: Re: appletalk error rates
Message-ID: <21511@ucbvax.BERKELEY.EDU>
Date: Thu, 29-Oct-87 18:33:41 EST
Article-I.D.: ucbvax.21511
Posted: Thu Oct 29 18:33:41 1987
Date-Received: Sat, 31-Oct-87 17:03:02 EST
References: <9083*sample@cs.ubc.cdn> <638@louie.udel.EDU> <4197@sdcsvax.UCSD.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: University of Melbourne (visiting CSRG, UC Berkeley)
Lines: 10

Remember that when you see "overruns" from appletalk peek, its peek
itself that had the overrun (ie: the peek process wasn't quick
enough reading the packet).  There's no way that "peek" can possibly
know whether the real recipient node had an overrun or not.

Similarly crc errors might be purely errors local to the mac running
peek, though this is considerably less likely.  These are likely to
be real transmission problems, or collisions.

kre