Conference netcad::hub_mgnt

    The PacketProbe uses the LANCE chip.  It only reports collisions
    that happened when it was transmitting so it can be a long ways
    off.
    
    There is a rather large report floating around that describes Ethernet 
    chip problems from the various manufacturers.  These "chips" find
    their way into lan analysers such as HP, etc. and can cause readings
    that aren't totally correct.
    
    dave

	We are planning a gate array change that will allow us to do a 
	Collision Counter workaround external to the LANCE chip. Hope to 
	be shipping it this summer.

	This is a hardware change, and there will be no upgrade for 
	existing modules.

>                       <<< Note 838.3 by NAC::FORREST >>>
>                  -< Hope to have this fixed by mid Q1 FY95 >-

>	Collision Counter workaround external to the LANCE chip. Hope to 
>	be shipping it this summer.

Any update on this?

Thanks,
_Tak

>>	Collision Counter workaround external to the LANCE chip. Hope to 
>>	be shipping it this summer.
>
>Any update on this?

Any takers???

thanks,
_Tak

I didn't find this topic early enough to avoid a small embarrassment at a 
customer site.  I have to say also that at this point I'm disappointed that 
the DECpacketprobe doesn't do a "better" job of detecting collisions on a 
LAN.

I ran the packetprobe side-by-side with an Excelan (Novell) LANalyser.  At
first the LANalyser was showing much higher numbers of "Local collisions & 
SQE events".  After we sorted-out some tranceiver heartbeat problems, the 
number of these came down significantly, but the total of these and "Remote 
collisions" reported was still higher than the packetprobe was reporting.  
The ethernet line counters of VAX/VMS systems on the LAN were also 
indicating higher collision rates.  I was embarrased by having no 
explanation for the differences.

.3, above, talks about the possibility of a follow-on product with ability to 
detect more collisions.  I've been led to believe that not only the LANalyser 
but also HP monitoring products, Network General Sniffer products, and 
Frontier's own NetScout will usually show higher collision rates than the 
packetprobe will.

Is there any conclusion possible other than that the packetprobe is simply 
deficient in this respect?  Should our field engineers and consultants 
consider doing something like using NetScouts with our Probewatch software 
when we have collision issues to resolve?  What are the chances that Digital 
will soon have our own product that is as good as or better than the 
competition in this respect?

If anyone reading this knows of related weaknesses in competing products as 
a result of flaws in their ethernet chips, as one of the earlier replies 
suggests, I'd be grateful if these cases were described here.


Malcolm

Comming soon, according to NAC::MANAGMENT:STATUS.TXT (as of 16-DEC).

I expect someone will announce here when they actually start shipping the 
enhanced packetprobe90. (Jack?)

_Tak

    I am trying to get a good estimate as to when the revised modules will
    begin to appear. As is often the case, economics plays a role. There
    was a desire to use up the stock of the old gate array, rather than 
    write them off in the Engineering budget. 
    
    I'll post another reply when I get an answer from Manufacturing.
    
    As for why the VAX was reporting a higher collision rate than the 
    DECpacketprobe, it was probably using the LANCE chip too. Since the 
    probe is normally listening, while the VAX could have a send/receive 
    balance, the VAX should be attempting to transmit much more often, and
    thus encounter more collisions.