mjhammel@Kepler.dell.com (Michael J. Hammel) (04/05/91)
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.jrd@cc.usu.edu (04/07/91)
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.
johnson@kelvin.jpl.nasa.gov (johnson, glenn) (04/09/91)
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 ..(deleted) >traffic gets heavy both packages seem to stop seeing packets. The ..(deleted) >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 ..(deleted) Yes, version 7 wd8003e had problems with Netwatch 0.30 for me too. I got version 8 along with the new Beholder from the Netherlands, and that fixed Netwatch 0.30 (don't get rid of 0.30, simple "source" display is missing from new beholder in favor of SNMP) (I heard the drivers are on version 9 now, but I haven't tried them...) Glenn Johnson johnson@kelvin.jpl.nasa.gov
geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (04/10/91)
Quoth jrd@cc.usu.edu (in <1991Apr6.173657.47299@cc.usu.edu>): # 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. However let me emphasize that this stuff about Suns is simply an old rumor... it's not true, never was true. We use LANCEs and 82586s just like everyone else, we don't play with their clocks... WD8003Es fall over all the time under load, and not just from Suns. -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- ------------------------------------------------------------------------------ -- Sun Microsystems PC Distributed Systems ... -- -- ... soon to be a part of SunTech (stay tuned for details) --
mjhammel@Kepler.dell.com (Michael J. Hammel) (04/12/91)
In article <5426@eastapps.East.Sun.COM>, geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes: > Quoth jrd@cc.usu.edu (in <1991Apr6.173657.47299@cc.usu.edu>): > # 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 I missed this followup somehow. Ah well. "Heavy traffic" could be loosely defined as a substantial increase in the number of packets being seen by either of my two monitors (Netwatch or the Beholder). Both deal quite nicely with TCP/IP packets, it appears, but when I start up the NFS-based traffic (UDP/IP) it saturates (at least in comparison to the TCP traffic I was running) the wire and the monitors stop reporting traffic information. I don't really think its a matter of UDP vs. TCP, though. Something about the packet drivers is not working (judgement call; I can't prove that yet). > #machines are reputed to shorten the normal small <random> breathing space > #between packets to a smidgeon, and hence the reputation SUN machines have. I'd never heard this, but it wouldn't apply in my case anyway. My test network contains about 15 systems, all Dell Systems, all running either Dell UNIX V4 or Dell's updated version of ISC's 2.0.2 w/TCP 1.2 or 1.1.2. No Suns around (at least in this testbed). > WD8003Es fall over all the time under load, and not just from Suns. Thanks for the clarification on the Suns. However, my problem deals with both WD8003EBs and 3Com 3C503s. Thats why I felt it was a packet driver problem. 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.
backman@FTP.COM (Larry Backman) (04/13/91)
>> >> I missed this followup somehow. Ah well. >> >> "Heavy traffic" could be loosely defined as a substantial increase in >> the number of packets being seen by either of my two monitors (Netwatch >> or the Beholder). Both deal quite nicely with TCP/IP packets, it >> appears, but when I start up the NFS-based traffic (UDP/IP) it saturates >> (at least in comparison to the TCP traffic I was running) the wire and >> the monitors stop reporting traffic information. I don't really think >> its a matter of UDP vs. TCP, though. Something about the packet drivers >> is not working (judgement call; I can't prove that yet). >> How many consecutive packets are you seeing? How big is your NFS Read/Write size. I'm willing to bet that your doing 8K read's/writes and the multiple consecutive IP fragments are blwoing away your WD card. If so; cut your NFS read/write size down to 2K and see if your problems go away. I've seen 3c503's behave the same way under NFS. Larry Backman backman@ftp.com
eason@npdiss1.StPaul.NCR.COM (Dale Eason) (04/17/91)
I too saw the packet drivers stop sending me packets. It also seems to fail on a commercial network monitor software without packet drivers (emonitor). Faillures occured with the packet driver on wd8003e and 3c503 drivers. Release 9 of the packet drivers has fixed it. I was going to invistigate it myself until I got version 9 drivers. I think the problem happened when the boards ring buffers overflowed and were not reset correctly. Then they no longer sent pakcets to the packet driver. Dale Eason -- Dale.Eason@stpaul.NCR.COM CAD/CAM Services NCR NPD Stpaul, MN.