Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!SIERRA.STANFORD.EDU!GROSSMAN
From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  danger of bridges
Message-ID: <12290865337.25.GROSSMAN@Sierra.Stanford.EDU>
Date: Tue, 31-Mar-87 17:19:46 EST
Article-I.D.: Sierra.12290865337.25.GROSSMAN
Posted: Tue Mar 31 17:19:46 1987
Date-Received: Thu, 2-Apr-87 02:19:28 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

Regarding DECnet HELLOs:

1) You are correct regarding the settability of the DECnet hello timers.
   These (by default) are 15 seconds, but can be set to any value, as
   timer value is sent out over the network for each host.
2) The hellos are sent to a multicast address that is only enabled by
   DECnet 'routers'.  Non-routers (known as 'endnodes') do not receive
   these messages.

Yes, these messages do eat up some Ethernet bandwidth, but intelligent
controllers pitch them if the host isn't interested.  I think the real
issue here is really "how often do I have to wait to acquire the
Ethernet?"  DEC controllers keep track of this information in a counter
known as "Deferred transmits".  My experience with a cable segment with
over 400 DECnet nodes, a bunch of LAT boxes and some TCP/IP traffic is
that this counter was quite low (well under 1% of all the transmits from
the node in question**).

It would be really interesting to find out the values of things like
deferred transmits, single collision transmits, and multi-collision
transmits vs. total transmits for various host and gateway interfaces.

			Stu Grossman

** Actual mileage may vary.
-------