Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cc.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: packet drivers losing packets or getting confused?
Message-ID: <1991Apr6.173657.47299@cc.usu.edu>
Date: 6 Apr 91 23:36:57 GMT
References: <17713@uudell.dell.com>
Followup-To: comp.protocols.tcp-ip.ibmpc
Organization: Utah State University
Lines: 53

In article <17713@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes:
> I'm running both Netwatch and Netcure (aka the Beholder v0.30) to
> monitor traffic on a test network.  I've noticed that as long as I don't
> start too much traffic (multiple instances of an NFS-based network test
> on various systems) both monitors keep up just fine.  As soon as the
> traffic gets heavy both packages seem to stop seeing packets.  The
> monitors are still running because the clock displays are running and I
> can get help or change windows, etc, in Netcure and get help, quit, etc,
> from Netwatch.  This leads me to believe the packet drivers stop passing
> packets up to the monitors for some reason.  Eventually Netwatch will
> start seeing packets again, then stop again, then start, and so on. 
> Netcure has done this too, but not nearly as often (only once that I've seen).
> 
> Has anyone seen similar behaviour from these packages or from other
> packages using the packet drivers?  I'm using the WD8003EB driver under
> Netwatch and the 3C503 packet driver for Netcure (both drivers are
> version 7.0).  Netwatch is running on a Dell System 210 with 4M (a 286
> 10MHz system) and Netcure is on a 386 20MHz system with 8M.  No other
> drivers of any kind are loaded.
> 
> Michael J. Hammel        | mjhammel@{Kepler|socrates|feynman}.dell.com
> Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
> #include <disclaim/std>  | zzham@ttuvm1.bitnet 
> "We choose to do this not because it is easy but because it is hard." J.F.K.
-----------------
Michael,
	You didn't mention what else was running in the monitoring machines
but the monitor programs will take only what other protocol stacks don't;
that's how I organized the promiscuous mode in Packet Drivers.
	Heavy traffic is kind of vague. I have no trouble monitoring with
either package when the packet rate reaches 500 pkts/sec around here, on
a WD8003E board in a Dell 310 386-20. As we know only too well, real SUN
machines are reputed to shorten the normal small <random> breathing space
between packets to a smidgeon, and hence the reputation SUN machines have.
If this were the case then it is possible to overwhelm a regular Ethernet
board with too many back to back SUN style packets, especially with a
slower monitoring system. Example: WD8003E board in a NetWare 3.10a server
using a 386/SX-16 and a dozen SUNs on the same side of the bridge zaps the
board a couple of times per day; the SUNs were doing NFS and X for EE CAD
things.
	The back to back effect can be checked a couple of ways. One is
to insert a handy 16-bit Ethernet board. Another is to borrow a scope for
an hour or so and put the Tee connector on its vertical input channel. If
you have a multiport receiver on the wire then they usually have light bulbs
which we can check for collisions and jams. If the repeater is a DELNI then
one can even achieve a one way repeater in some cases (which has the name
DELNI effect around here, from addition and relaying of IEEE's dim idea of
adding collision det jam bursts at the end of every packet to ensure the
electronics are ok).
	Netwatch works fine here, by construction, and "Beholder" has
operated ok (mostly) in brief tests. The latter has exit paths which do
not decouple from the Packet Driver and hence crash the machine.
	Joe D.