Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet "heartbeat"
Message-ID: <105132@sgi.sgi.com>
Date: 20 May 91 20:13:36 GMT
References: <12164@uwm.edu> <1991May16.004523.21301@berlioz.nsc.com> <1991May20.165442.23834@amd.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 31

In article <1991May20.165442.23834@amd.com>, phil@brahms.amd.com (Phil Ngai) writes:
> 
> I would say [count of missed heartbeats] ought to be maintained as a
>	statistic by the driver
> and accessible via ioctl.

If it's just available via ioctl, then what good is it?  Those of us who
might write a program to fetch the count it are as likely to have the spare
hardware to try some easter egging.  The rest would still be in the dark.

>                           Ideally, you'd bug the system manager about
> no SQE, but realistically, you'd probably get calls from people who
> don't understand 802.3 and don't want to.

This sounds like an argument against a printf.

> As far as printf on first missing heartbeat, what does "first" mean?
> What if someone unplugs the AUI cable for network maintenance and
> then reconnects it an hour later?

I meant "first" as in "first missing heartbeat after initialization or after
having seen heartbeats."  I'd suppress the printf if there were a
"simultaneous" no-carrier report, which covers most disconnected cables.


Others have written bad words about printf's.  So until and unless there is
something in a SMTP MIB, I guess the count will stay a secret here.



Vernon Schryver,   vjs@sgi.com