Re: Network diagnostics

[barmar@Think.COM (Barry Margolin)]

    Date: Thu, 8 Feb 90 11:37 PST
    From: TYSON@Warbucks.AI.SRI.COM (Mabry Tyson)

    Barmar, are you aware of SYS:NETWORK;CHAOS-PERF.LISP?  It has some
    performance tests that are useful.   (Under separate cover, I'll send
    you some code that I have that sits on top of this.  The Chaos testing
    stuff is a lot better than my feeble attempts at doing ICMP echoes.)  If
    your question is regarding sending vs receiving, this should help.

Unfortunately, the CHAOS-PERF code seems to be using servers that don't
exist.  It tries to invoke Chaos servers named ECHO, SINK, and SOURCE,
but times out in all cases.

I've got my own Ping command, which uses ICMP Echoes.  I modified the
ICMP routines so that the TCP:SEND-ICMP-ECHO returns the number of
microseconds between the echo and its reply (instead of just T and NIL),
so my Ping command's output looks very much like Unix's.

    As I recall it is possible to put the interface into promiscuous mode but I
    don't know of any code that would use it.

Others have sent me such code.  Here's how you do it on an L-machine:

(setf (ldb sys:%%net-promiscuous-mode sys:%network-mode) -1)

    Most of my problems on our net tend to be with intermittent problems that
    are very hard to track down.  I've put a TDR on the net but the net is
    relatively clean.  The problems tend to be a transceiver goes bad (we still have
    some old level 1 vampires from the Dandelion days) or when the I/O on the
    computer is having problems (eg, I/O board on Lispms but the same type of
    problem has occurred on Suns).

We have other tools for debugging general network problems.  We have a
SpiderMonitor (a standalone network monitor) and intelligent multiport
repeaters that can be told (over the net, even) to shut off individual
ports.  Our network is almost all thinnet and repeaters, so we no longer
have to run around partitioning the net.  We also have the Lispms
electrically isolated from everyone else using an Ethernet learning
bridge.

Now if we could only get our Appletalk network working as well....

    We have done some of our own wiring of transceiver cables and, once, the
    person who did it didn't pay attention to the way the pairs were
    supposed to go (ie, they weren't paired).  We then had a machine that
    could talk to some hosts but not to others.

We've gotten out of the habit of hacking up our own devices, and we're
much happier this way.

    Some of our most recent problems have been when we had someone running Prolog
    on a Sun.  The machine wound up thrashing and was using 40% of the bandwidth
    of the net.

We've been using subnets to keep diskless workstation paging from
interfering with general traffic.

    Our usual way of tracking down intermittent hardware problems is to bisect the
    net repeatedly.  (Hmmm... Some of our multiport transceivers have LOOPBACK
    switches.  That's probably a good way to isolate them.)  However some of the
    problems tend to disappear when the net is broken and then reassembled (with
    a section missing).

That was our old way of tracking down network problems.  It's also
useful to have repeaters with decent lights; DEC DELNI's are no good,
while Cabletron MT-800's were pretty good (you can see its CP light from
across the room).

                                                barmar