[Info-vax] hub better than switch?!

[John Wallace]

On Mar 6, 8:08 pm, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <jj5ijk$q9... at dont-email.me>, Albrecht Schlosser
>
> <vms-n... at go4more.de> writes:
> > $ LANCP show dev ewa0 /count
>
> Output below.
>
> > These counters can maybe shed some light on what's going on.
>
> Thanks!
>
> > The way to reset the counters is easy to remember ;-)
>
> > $ LANCP SET DEVICE /DEVICE_SPECIFIC=FUNCTION="CCOU" ewa0
>
> Extracted to file for future reference!
>
> > BTW.: One rule of thumb is to have both devices (switch and
> > connected device) do the same with auto negotiation, either
> > on or off. Bad if you have a switch that can't turn off auto
> > negotiation, but maybe turning it off at the VAX (?) can help
> > anyway.
>
> No VAX, all ALPHA.
>
> JANDER Device Counters EWA0 (6-MAR-2012 21:06:36.04):
>                   Value  Counter
>                   -----  -------
>                 7624255 Seconds since last zeroed
>             75977683821 Bytes received
>             33942574655 Bytes sent
>               212326266 Packets received
>               146920428 Packets sent
>               895734754 Multicast bytes received
>               426142710 Multicast bytes sent
>                 7256200 Multicast packets received
>                 3450890 Multicast packets sent
>                       0 Unrecognized unicast destination packets
>                      42 Unrecognized multicast destination packets
>                       0 Unavailable station buffers
>                       0 Unavailable user buffers
>                       0 Alignment errors
>                       0 Frame check errors
>                       0 Frame size errors
>                       0 Frame status errors
>                       0 Frame length errors
>                       0 Frame too long errors
>                       0 Data overruns
>                       0 Send data length errors
>                       0 Receive data length errors
>                       0 Transmit underrun errors
>                       0 Transmit failures
>                      23 Carrier check failures (26-FEB-2012 16:42:15.42)
>                       0 Station failures
>                11249851 Initially deferred packets sent
>                 1651656 Single collision packets sent
>                 1803849 Multiple collision packets sent
>                       9 Excessive collisions (26-FEB-2012 16:21:12.36)
>                       0 Late collisions
>                       0 Collision detect check failures
>                       4 Link up transitions (26-FEB-2012 16:43:14.64)
>                       3 Link down transitions (26-FEB-2012 16:43:13.02)
>    26-FEB-2012 16:43:14 Time of last generic transmit error
>                    None Time of last generic receive error

Carrier check failures aren't a good sign, but there aren't many of
them, and it's been a few days, and presumably you've been tinkering
with cables or interfaces or both?

I've lost track of what box/interface is configured with what
settings.

I presume the above display isn't from an interface you are expecting
to be full duplex, right?

My understanding was that with full duplex properly configured, you'd
not see things like "initially deferred" or indeed anything collision
related because the properly configured switch with full duplex at
both ends of a cable handles all that by magick.

Zero the counters and come back in a day or so?

In the days of DECnet line counters you could set a counter timer so
the counters would be automagically cleared after some manager-
specified interval (and optionally recorded to a file or to OPCOM).
I'm not aware that LANCP has that capability, but a little DCL could
achieve the same result. See also counter snapshots on DECnet-Plus.