| Ed
> Short of putting a data line monitor on the line, is there a
> way to determine exactly what is causing it...jabber, collisions, etc.?
Not from the 90C using HUBwatch or ClearVISN. Your only option is to use
either a packet probe, or a datascope of some description. Some of the
older repeaters, not sure about this one, had to wait for 64 collisions,
and then it would partition the port. May be the folks in engineering
would post the algorithm used by the 90C.
> Also when does that counter get reset? Is it only during a
> reboot of the module or should it reset by turning the port off
> and back on again?
I tried to reset my counters this morning, and it took me 4 or 5 power
cycles. If you hit the refresh button too soon after a power cycle then
you should expect to see a few strange things like the port number for
all of the ports becomes -10. After a few seconds it was OK. But it still
took a good 4 or 5 power cycles before any affect was visible. So no,
you can't just turn the port off and then back on.
> And lastly, should they be concerned w/ partition
> counts that high?
Depends on the uptime of the repeater, and if there is anything plugged
into the ports. If the repeater has been up for 6 months, has a segment
plugged in with stations working off it, and you have about 200 then how
often is the segment being broken. Well about 200 times. If there is
Nothing pluged in, then you should not see the counter increment at all,
as far as I am aware. Because once the port is auto partioned, the
counters tend to stop rising.
But I would seriously look into those segments that have a high count.
Thinwire is renowned for shorts, and opens, and this is the kind of fault
that could also cause the counter to rise.
Hope that helps.
Steven F
|