James B. Byrne wrote:
> Situation has cleared but source of problem remains unknown.

Your linkcontrol showed the following "interesting" numbers...

> Transmits no error         3973  Receives no error        16433
> Transmit byte count      966879  Receive byte count     1297727
> Transmits error             739  Receives error               0
> Transmits deferred          360  Carrier losses               1
> Transmits 1 retry          1890  CRC errors                   0
> Transmits >1 retry         1099  Frame losses                21

Receives are reasonably clean.  Transmits are an issue, errors,
deferred, or retried.  I'd have to defer to James Hofmeister or another
HP tech to tell you exactly what the 3000 counts in these categories,
but I will take a stab at the general interpretation.  You said this is
10Mb/Half-duplex.  Since you are running 10/half, we have to consider
CSMA activity, in this case the CS half (carrier sense).  If you have a
packet to transmit but the line is "busy" you have a deferred transmit. 
If still busy, it will re-queue and retry later.  If the maximum retries
are exceeded (or buffer space exhausted) you'll have to drop/discard the
packet, likely generating the errors.  All of your "issues" appear to be
related to CS.  So what is holding the line busy?

Your FS116 has 16 ports and 512K of shared buffer space (or so says
netgear's specs webpage).  It does appear to be a bona fide switch, so
the "actual" carrier busy case would only be true while the switch was
transmitting.  The other possibility is that of flow-control.  The FS116
has 802.3x flow-control for 100Mb/full, but may "emulate" flow-control
on the half-duplex ports by holding the carrier high, a trick employed
by several switch manufacturers when they run out of buffer space.

I'd guess that you are getting some relatively high traffic through
other ports of the switch, and the switch has run out of buffer space. 
Or there is congestion upstream of this switch with another traffic
source on this switch (or downstream). 

Another candidate is this switch doing "speed translation" of a 100Mbps
feed to a 10Mbps receiver, especially if it is a UDP-based, asynchronous
source like streaming media or multicast traffic.  That will eat up
switch buffer space.

You aren't showing any collisions or CRC errors, which are indicators of
a speed/duplex issue.  You've got a clean shot between the switch and
the 3000, but there's a bottleneck elsewhere.

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *