Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!im4u!halley!bc From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.protocols.tcp-ip Subject: Re: Proteon's behaviour Message-ID: <369@halley.UUCP> Date: 27 May 88 08:48:32 GMT References: <880519-134446-6569@Xerox> <2773@umd5.umd.edu> <22924@bu-cs.BU.EDU> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 32 In article <22924@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: >In article <2773@umd5.umd.edu> hans@umd5 (Hans Breitenlohner) writes: >>In article <880519-134446-6569@Xerox> Burrell.osbunorth@Xerox.COM, castillo.osbunorth@Xerox.COM writes: >>>It seems that the Proteon does some self testing of both of its Ethernet >>>interfaces and other internal hardware by sending small trash packets to itself >>>every so often through both interfaces. >>Two packets are sent out every 3.5 to 4 seconds. While this can be annoying >>in many respects, it is hard to see how this could consume much bandwidth. > If the router does not have a hardware interface test >capability, it's a pain when the interface doesn't work. Without a >test, it can't even detect a missing xcvr cable. I think you should >value the interface test. Software that generates timed transmissions, especially broadcasts, should have some facility for the interval to be tunable. In addition to Proteon's activity, I know Bridge network management has a 45-second "here I am" thing it does to keep net maps up to date. Keep-alives are popular topics of net conversation anyway, but tunable intervals seldom get much air time. I've certainly seen my share of networks with rwho disabled for this reason, too. In most cases, tuning would have to be coordinated netwide, although cases like the Proteon interface test would be easier to manage. When you add all these things together on a large LAN, you'd be amazed at the residual background activity. -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc