[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

2293.0. "Probe errors are different when comp to sniffer" by NZOV02::VICKERY () Thu May 18 1995 22:56

    Hi
    
    I hope someone can provide me with the answer to this problem
    
    
    I have installed a probe and I am running probewatch for windows 3.1.
    It tells me that I am having approx 300 crc/align errors per 30
    seconds. when the network peaks at 30% utilization.
    
    I am also running concurrently the General Sniffer this tells me there
    are no errors on the network.
    
    
    When I look further at probe watch hosts list none of the hosts
    generated any errors. ie the errors the probe picked up did not
    contain where the error came from. 
    
    In addition Runts Jabbers etc are all 0 on the probe stats, collisions
    climbed to about 12.
    
    Questions
    1. Do I have a network problem???
    2. Which is correct the probe or the sniffer?
    3. If the probe is correct how do I find the source of these errors?
    
    
    
    Any help would be appreciated.
    
    
    Regards
    
    Ian Vickery

T.R Title User Personal
Name Date Lines

2293.1 probably an Ethernet chip difference? NAC::FORREST Fri Jun 02 1995 17:33 23

T.R	Title	User	Personal Name	Date	Lines
2293.1	probably an Ethernet chip difference?	NAC::FORREST		`Fri Jun 02 1995 17:33`	23
	At first guess, I would say that the Sniffer is more likely to be right - they have been shipping for years with a large installed base, and are often used in lab environments, where the user knows whether errors are being generated or not. The difference is likely due to minor differences in Ethernet controller chip design. In an attempt to explain why the DECpacketprobe is picking up the errors and the Sniffer isn't, I will relate something that I observed a long time back. We had a MicroVax that would not download from a VAX host. The VAX host was reporting CRC/Alignment errors, but the HP Analyzer we had on the segment said the packets were fine. Luckily we were in a lab and had some special equipment to look at the raw signals on the cable. The packets from the MicroVAX had an extra bit at the end of the packet, so the packet didn't really end on an 8 bit boundary. From my perspective, the LANCE chip on the VAX was calling it right as an alignment error, while the HP was saying it wasn't a CRC error - I can't remember if it reported alignment errors. This theory doesn't explain why you aren't seeing any errors on the Host List - maybe your Host table is maxed out, so the offending packets are being counted.

    At first guess, I would say that the Sniffer is more likely to be 
    right - they have been shipping for years with a large installed 
    base, and are often used in lab environments, where the user knows 
    whether errors are being generated or not. 
    
    The difference is likely due to minor differences in Ethernet
    controller chip design. In an attempt to explain why the DECpacketprobe 
    is picking up the errors and the Sniffer isn't, I will relate something 
    that I observed a long time back.
    
    We had a MicroVax that would not download from a VAX host. The VAX 
    host was reporting CRC/Alignment errors, but the HP Analyzer we had 
    on the segment said the packets were fine. Luckily we were in a lab 
    and had some special equipment to look at the raw signals on the cable. 
    The packets from the MicroVAX had an extra bit at the end of the
    packet, so the packet didn't really end on an 8 bit boundary. From my 
    perspective, the LANCE chip on the VAX was calling it right as an
    alignment error, while the HP was saying it wasn't a CRC error - I
    can't remember if it reported alignment errors.
    
    This theory doesn't explain why you aren't seeing any errors on the
    Host List - maybe your Host table is maxed out, so the offending
    packets are being counted.