Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans
Subject: Re: Starlan/Ethernet compatibility
Message-ID: <36822@sgi.SGI.COM>
Date: 26 Jun 89 19:37:15 GMT
References: <2009@wasatch.utah.edu> <2230006@hprnd.HP.COM> <26097@amdcad.AMD.COM> <26111@amdcad.AMD.COM>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 28

In article <26111@amdcad.AMD.COM>, sdjmc@amdcad.AMD.COM (John McCool) writes:
> 
> AMD's SUPERNET chipset for FDDI is capable of sending
> directed beacons during ring recovery. In addition, the chip set WILL  
> receive beacons in buffer memory if the destination address
> matches the node's address (or is a broadcast).
> 
> John McCool
> Advanced Micro Devices
> 802.3 Network Products   
> (408)749-2302

That is encouraging.  Since the new directed beacon is to a "multicast
address", will a network manager using AMD's SUPERNET have to go into
promiscuous mode to receive the beacon?  Or have external address detect
hardware?  Of course, in the case of the directed beacon, we know we're
stuck at beacon, and so have plenty of time to reset the FORMAC into
promiscuous mode.

Please note that the original topic was standards processes.  It looks as
if AMD survived Wednesday's change, aside from the hassle of promiscuous
mode.  However, there are plenty of SMT meetings left where the problem
that AMD's current silicon is usable can be fixed.  Not that anyone with
much memory needs more evidence of the dangers of standards meetings.

Vernon Schryver
Silicon Graphics
vjs@sgi.com