Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!bruce!trlluna!blaise.trl.OZ.AU!hayes
From: hayes@blaise.trl.OZ.AU (Mark Hayes)
Newsgroups: comp.dcom.lans
Subject: Re: LANalyzer User Feedback
Message-ID: <2683@trlluna.trl.oz>
Date: 11 Feb 91 23:04:35 GMT
References: <1991Feb4.221957.23993@infonode.ingr.com>
Sender: news@trlluna.trl.oz
Reply-To: hayes@blaise.trl.OZ.AU (Mark Hayes)
Organization: Telecom Research Laboratories, Melbourne, Australia
Lines: 50

In article <1991Feb4.221957.23993@infonode.ingr.com>,
jarmond@infonode.ingr.com (Don Jarmon) writes:
> I have taken on the task of evaluating various models of network
> analyzers.  I was looking for user response before filling out the
> P.O.   Thanks in advance for any feedback.
> 

I would suggest that any potential purchasers of LANalyzers should 
firstly look carefully at their requirements, eg. is it more 
important to capture every packet to the buffer or is the format
and presentation of the data more important.

The next thing to do is get one of each machine and test it in 
your own environment without the sales rep. being present. This
way you can determine how easy it is to use and how well it
performs without being pressured by the sales rep. When we were
looking for a LANalyzer we tested a few in our lab under test
conditions which were rather extreme, but were indicative of our
requirements. 

Our prime requirement was that it capture *ALL* packets to the 
buffer (until full). It was interesting to discover that only one
machine was able to meet this criterion, dispite the claims of the
other vendors! It was also interesting to discover which machines
were easy and intuitive to use and those which were cumbersome.
We also discovered what we concluded were faults in a couple of 
machines, in that they reported wrong events, eg. runts which
never occurred.

Another factor which may need to be taken into consideration is 
the easy of programming the machine to perform tests such as send
a packet and time the delay until a reply is received, etc.

I must say that we had a good time over a couple of weeks stressing
these LANalyzers and putting pressure back onto the sales reps!

I hope these comments may be of use to some people.

Cheers,
mdh

ps. We purchased the HP4972A as it was the only one which captured
all packets at all traffic levels. It is also quite a nice machine
to use once you know your way around and I enjoy programming tests
which cut down our measurement times from 5 days to 1 day. Our
main application is basically development and testing rather than
network monitoring.
-----------------------------------------------------------------
Mark Hayes					Research Labs,
m.hayes@trl.oz.au				Telecom Australia