Conference netcad::hub_mgnt

	Roland, sorry I am so slow to answer. The DECpacketprobe 90 will 
	start counting some packets as missed above about 30% sustained 
	utilization. It counts a packet as missed if it is too busy processing 
	the previous packets to properly count the new packet properly. 

	You would have to add the missed packets to the good and error 
	packet counts to get an idea of the total. Other statistics are 
	not completely valid anymore, but if the number of missed packets 
	is very small relative to the total, then the other statistics are 
	pretty useful.

	Filtered counts are in addition to total counts; you can't disable 
	the total segment statistics. Thus you will aggravate the problem 
	by adding filters or specific domains.

	Another limitation of our implementation is that we use the 
	LANCE chip, like almost all of the other Digital Ethernet 
	products. Unfortunately, the LANCE only counts Collisions when 
	it is trying to transmit. Thus, the Collison count for the 
	segment is grossly understated.

	I hope this helps.

    .1�	Roland, sorry I am so slow to answer. The DECpacketprobe 90 will 
    .1�	start counting some packets as missed above about 30% sustained 
    .1�	utilization. It counts a packet as missed if it is too busy processing 
    .1�	the previous packets to properly count the new packet properly. 
    
    How does that compare with competitive Ethernet Probes ? I have the NAT
    product in mind ...
    
    Thanks in advance,		Patrick

    If it only counts collisions that it has caused then does that mean
    we are not compliant with one of the nine RMON groups???
    
    From the PROBEwatch for ULTRIX SPD:
    
>>   The Ethernet version of RFC 1271 calls for nine separate
>>   groups of MIB objects. The nine groups are:
    
>>   Segment statistics - counters for total number of packets,
>>   octets, broadcasts, COLLISIONS, dropped packets, fragments, 
>>   CRC/ alignment errors, undersize and oversize errors, and jabbers; 
>>   each packet
    
    Collisions are very important as we had a customers network go down
    because a small change caused a 50% collision rate.  Fortunately
    a PC with some monitoring software showed the collision rate climbing
    at half the packet rate and the problem was quickly traced back
    to the change.  If the DECpacketprobe 90 cannot show an accurate
    collision count then we are missing a sometimes important number
    especially when trouble shooting a bad network.
    
    Will another chip other than the LANCE chip be used to provide an
    accurate count??
    
    Thanks,
    dave
    

    .2� How does that compare with competitive Ethernet Probes ? I have the NAT
    .2� product in mind ...
    
    The ARMON ONSITE Ethernet Probe, that was shown at INTEROP, looks
    pretty good (on paper). We need competitive data.

    Any comments on the LANCE chip and the packetprobe's ability to
    display the correct collision numbers?
    
    dave
    

    .0�We read that the limit of the packetprobe 90 module is 30% ethernettraffic.
    .0�After the module will loose packets.
     
    May I insist on feeding us ASAP with reliable competitive info. We have
    spent years telling prospective customers that most probes or sniffers
    on the market were no good because they failed to count all packets
    unlike our 911 (LTM) which was capable of watching 14880 frames per
    second.
    
    Now we have a product (DECpacketprobe90) that displays the same
    erratic (statistical) behaviour. What about the other DEC distributed
    product: NAT Ethermeter ? Does it count all 14880 frames per second ?
    
    Thanks for giving us accurate and positive selling arguments.   

I'm still unclear on what the 30% "sustained" utilization really means..  
Would someone elavorate on it please.

One of the reasons why customers show their interests in monitor products 
(sniffer, LTM, LTM-Report, HP LAN Probe, etc) is that they really have
no idea on thier Ethernet utilization.  They purchase a product because 
they want to know.  Some LAN segments might be showing less than 30% on 
avarage utilization graph, others might be more than 40% or 50%, while
showing 65% or 75% peak on occasion.  They only know after they buy a
product and measure segments with it.   Under these unknown environments,
what the limitation of 30% sustained utilization brings us?   They don't
have any numbers (utilization, or traffic patterns for strictly speaking) to
judge the 30%.   

_Tak

    Since it was brought up in .1 about counting collisions and I asked
    for clairification, I'm hoping someone will try to answer the question.
    
>>	Another limitation of our implementation is that we use the 
>>	LANCE chip, like almost all of the other Digital Ethernet 
>>	products. Unfortunately, the LANCE only counts Collisions when 
>>	it is trying to transmit. Thus, the Collison count for the 
>>	segment is grossly understated.

    What's happening here?  Do we correct the SPD to reflect that we
    don't count collisions in a manner that has any meaning or is there
    something being planned with the hardware to correct this?
    
    dave

    
    	Note 52 in the NOTED::LTM conference discussed the LANCE limitation
    in the LANbridge monitor. Simple fact is that the LANCE only monitors
    for collision during Xmit and CPT window.
    
    	The HP 4972 uses a National Semi. chip which allows measurement of
    received collision states. The downside is that it counts CPTs as 
    collisions too. So, if you are monitoring via a DELNI the collision
    rate will be grossly out of line if the DELNI is "doing" CPT.
    
    	I'd like to know if competitor's products which (may?) be able to
    count received collisions make any notice of the effect of connecting
    their probe to a MAU supplying CPT....
    
    	Looks like each approach has limitations IMHO.
    
    Phil
    
    	
    

    	FWIW, there is a discussion of the HP4972's collision measurement 
    limitations in Note 18 of the BULEAN::HP497X conference.
    
    	One opinion there states that measurements of the collision rate on 
    a DELNI without CPT is questionable as well...
    
    Phil

	Sorry, I just can't seem to get around to Notes each day...

	First the collision counter issue
	We are looking at an onboard workaround to the LANCE limitation. 
	This could possibly be on shipping modules within 3 months. A 
	chip change to another vendor's part is much more involved, and 
	would necessitate a much longer effort. No decision has been made 
	on that yet.

	On the performance issue
	We haven't had a chance yet to get a total characterization of 
	performance. We also don't have any competitive product to 
	characterize against, and I haven't seen their specs in any of 
	their literature. I would guess that we are roughly equivalent 
	to NAT's newer product and to HP's product. We should easily 
	outperform NAT's older product. Obviously, we do not keep up 
	with some of the RISC based probes.

	The 30% number was measured by sending a continuous flow of 
	128 byte packets. The number goes way up when you start throwing 
	in some maximum length packets. On an average network, there are 
	a sufficient percentage of longer packets such that we can handle 
	a much higher utilization. We intend to characterize the performance 
	more fully as soon as we can free up some time.

	A redesign for performance  would require at least a gate array 
	change and possibly some other custom circuitry. We have a chicken 
	and egg situation - we have to see some volume demand building up 
	before we go off and make this investment. What I don't want to 
	hear is that we can't sell the existing product at all due to its 
	performance limitations, when NAT has been selling their low 
	performance probe for years with much success.

    Thanks for the inputs. We definitely need real hard facts on the
    DECprobe and on the competition. Isn't there a budget to do this ?
    
    .11�	with some of the RISC based probes.
    
    Do you have names ?
    
    Other questions on the LAN probe topic: are you developing or planning
    to develop similar probes for: 	- Token Ring (4/16)
    					- multiple Ethernets (hub based)
    					- FDDI
    					- others ?
    
    Thanks in advance.