dnwcv@dcatla.UUCP (William C. VerSteeg) (06/17/88)
The consensus on lights vs. no lights on lan equipment seems to be overwhelming in favor having status lights. The question then becomes - What status is of interest ? Here are a few that I think are important. Are there more ? Are any of these unneeded? Box status indicators _____________________ Power on indicator Box running/loading indicator Interface status indicators ___________________________ Receive Data Transmit Data Media Error (i.e. Collisions, no Carrier, etc) Please post repies to the net, as I believe this to be a topic of general interest. Bill VerSteeg DCA Standard Disclamer goes here.
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (06/21/88)
In article <5808@dcatla.UUCP> dnwcv@dcatla.UUCP (William C. VerSteeg) writes: >The consensus on lights vs. no lights on lan equipment seems to be >overwhelming in favor having status lights. > >Box status indicators >_____________________ >Power on indicator >Box running/loading indicator > > > >Interface status indicators >___________________________ >Receive Data >Transmit Data >Media Error (i.e. Collisions, no Carrier, etc) I think you also need: SQE (Heartbeat) enabled There is a difference in what is required for bus versus star topology Ethernet. As an example, Cabletron defines 5 status lights for a bus transceiver: Power, Receive, Transmit, Collision, SQE enabled. All of these are very useful for bus transceivers: Power= is this transceiver plugged into anything? Rcv/Xmit= is data flowing both ways? Collision= are there too many collisions (get the analyzer)? SQE= do I have a problem with heartbeat (on a repeater)? For star topology (UTP of fiber) they define two more signals for the point-to-point MAU to concentrator [not IEEE jargon]: Host Link OK Hub Link OK These signals are not data signals. They indicate a good or bad circuit and may eliminate the need for TDRs, special analyzers or breakout boxes. If Link OK not lit, then find the open or crossed circuit. Very, very useful. When forced to eliminate all but two lights on hub concentrators and MAUs, Cabletron chose to keep Link OK and Rcv. Seems reasonable to me. One more thing. It's very very important that vendors implement the IEEE repeater fault protection functionality. Just because they spec 802.3 compatible doesn't mean they implement the fault isolation feature= make sure they implement the fault isolation. Isolation is based on too many consecutive collisions or jamming and provides for automatic recovery. You really need this feature to isolate hardware faults and to allow you to unplug things for debugging. I am not sure of existing vendor compliance, but I think most of the star concentrator equipment will have this feature. Kent England, Boston University
rpw3@amdcad.AMD.COM (Rob Warnock) (06/24/88)
+--------------- | One which occasionally is very bothersome here ... | On these terminal server boxes (in our case, UB NIU-180's), have | a light per port saying if it's busy. Maybe two lights -- one that | it's in use and another saying that i/o is active. | <---- David Herron - <david@ms.uky.edu> +--------------- Long time ago at Dig. Comm. Assoc. (DCA), on our statistical multiplexers we supplied a single LED per port, encoded this way: 1. Idle port, LED is off. 2. LED flashes on in time with "RING". 3. LED comes on solid with carrier (CD) [or DSR, some configs], but... 4. ...flashes *off* for received/transmitted data. It took a new customer or tech all of 30 seconds to learn to correctly interpret what was going on with any given port. (The "ring" flashes were *never* confused with "data".) Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403