%META:TOPICINFO{author="ChrisBartram" date="1219018399" format="1.1" version="1.1"}%
%META:TOPICPARENT{name="Hp3000NICs"}%
---+ How to determine settings of a 100Bt network card on an Hp3000
LINKCONTROL - if you have a 10/100 card, check for the "Link speed" and "Link duplex" as shown below.
Here's an example showing a 10/100 card and a standard 10Mb card in the same box...
:linkcontrol @;status=all
Linkname: LINK100 Linktype: 100BT Linkstate: CONNECTED
Physical Path: 0/28/4
Current Station Address: 08-00-09-DA-30-59
Default Station Address: 08-00-09-DA-30-59
Current Multicast Addresses:
09-00-09-00-00-01
Transmit bytes 37997117 Receive bytes 4316183936
Transmits 444665 Receives 353070
Transmits no error 444665 Receives broadcast 48676491
Transmits dropped 0 Receives multicast 74801
Transmits deferred 0 Receives no error 89257950
Transmits 1 retry 0 CRC or Maxsize error 0
Transmits >1 retry 0 Code or Align error 0
Trans 16 collisions 0 Recv dropped: addr 40153588
Trans late collision 0 Recv dropped: buffer 0
Trans underruns 0 Recv dropped: dma 0
Carrier losses 0 Recv dropped: other 0
Link disconnects 0 Recv deferred 68
Link speed 100 Recv overruns 0
Link duplex Full Link auto sensed Yes
Link mode 100Base-TX Secs since clear 7074477
Linkname: DTSLINK Linktype: IEEE8023 Linkstate: CONNECTED
Physical Path: 0/28/44
Current Station Address: 08-00-09-D0-DC-B1
Default Station Address: 08-00-09-D0-DC-B1
Current Receive Filter: broad(1) any(0) k_pckts(1) x_pckts(0)
Current Multicast Addresses:
09-00-09-00-00-01 09-00-09-00-00-03 09-00-09-00-00-04 09-00-09-00-00-06
Transmits no error 697 Receives no error 88933049
Transmit byte count 734514 Receive byte count 3328553641
Transmits error 0 Receives error 0
Transmits deferred 0 Carrier losses 0
Transmits 1 retry 0 CRC errors 0
Transmits >1 retry 0 Frame losses 10
Trans 16 collisions 0 Whole byte errors 0
Trans late collision 0 Size range errors 0
802 chip restarts 0 Receives dropped 3
Heartbeat losses 0 Receives broadcast 87938989
Receives multicast 104880
--[[ChrisBartram]]
True of 100BT interfaces, I don't think the old MIO card 10mb interfaces would do anything but 10/half.
The HP-branded 100BT interfaces, at least prior to the A-/N- class, were notoriously bad at duplex autonegotiation.
And yes, they can be nailed at a speed/duplex in NMMGR.
--[[JeffKell]]
The current *accurate* setting for the 100BT card is as displayed with linkcontrol, this may differ from the configured value if the network has not been stopped / restarted since the last configuration change.
:linkcontrol @;status=all
....
Link speed 100
Link duplex Full
Link auto sensed Yes
Link mode 100Base-TX Addon
Note: In my testing with 100BT card on my a-class 3000 with procurve switches 2224, 2708 & 4000M - With the 2224 & 2708 procurve plug & play switches I found it is important to specify 100/FULL/Auto in the 3000 configuration to achieve a working connection. If Auto negotiation was not specified, it flat out did not work; - With the 4000M procurve manageable switch I found Auto negotiation in the 3000 configuration worked. I found the 3000 configuration Auto negotiation = NO worked as long as the switch configuration matched with Auto = NO.
Note: Do not mismatch Duplex with the actual capability of the attached network device. Most 100BT hubs will only operate at Half Duplex, whereas most 100BT switches will operate at Full Duplex. It likely will be necessary to "hard code" the configuration of the 3000 for Half Duplex, NO Auto negotiation as Auto negotiation does not seem to work well to the 100BT hubs I tested with.
The field "Recv dropped: addr" includes frames which are received by the LAN card, but a server is not present to pass the buffer pointer to. You may/will see many high counts of this where a e-3000 is present on a network where multi-vendor or multi-platform traffic is present. Many of these "Recv dropped: addr" frames are broadcast thus you will still see high counts on systems, even if this system is on a switch port which isolates IP
traffic. Yes as noted by others you will see higher counts on the 100BT
cards than on the 10MB cards in the 3000. The 10MB card has additional filtering which discarded frames in the LAN hardware whereas the 100BT card is a more industry standard card thus the filtering is performed at the driver layer and hence the "Recv dropped: addr" are recorded.
Well, after having said all of this... It is easiest to tell if you have a configuration miss-match between 3000 and a switch or hub network device by looking at several of the **more** interesting fields in the 3000 linkcontrol output. In my testing if you see values in the following fields you may have a miss-match in configuration with either duplex or speed:
Trans late collision
Recv CRC error
Recv Maxsize error
Assuming the link statistics and configuration is clean.. we then would suspect possible "wide area link" outages or "wide area link" saturation.
The easiest way to identify this is through TCP Retransmissions. You can use the nettool TCP status output to retrive the current retransmission count, then test run the transfer and continue to use the nettool TCP status output again to determine the difference in number of retransmissions. For each TCP retransmission you can add **at least** a 1 second delay in your file transfer and possibly a lot more depending on TCP timer configuration and the actual problem being experienced on the network.
:nettool.net.sys;info="status;tcpstat;tcpglobal @;quit"
....
Cumulative Statistics
....
. Total re-transmitted segments : 132
----------
The TCP timer configuration is in NMMGR at screen: NETXPORT.GPROT.TCP
[Y] Checksum Enabled (Y For Yes, N For No)
[4096 ] Maximum Number of Connections
[1 ] Retransmission Interval Lower Bound (Secs)
[360 ] Maximum Time to Wait For Remote Response (Sec)
[2 ] Initial Retransmission Interval (Secs)
[8 ] Maximum Retransmissions per Packet
These are the current TCP Timer settings I use on my e-3000 to accommodate my marginal quality home DSL link. If I had recorded the above 132 Total re-transmitted segments during 1 file transfer, then the minimal amount of time this file transfer would of increased would of been 132 seconds. That is assuming that 1) In the configuration above I have set the "Retransmission Interval Lower Bound" to a value of 1. If your value is larger, your minimal delay can be computed by multiplying the configured value for the "Retransmission Interval Lower Bound" times the increase in "Total re-transmitted segments" displayed by TCP stats. ~and~ 2) that I did not have to retransmit the same packet multiple times to successfully get it to transfer over the link.
One other side note... performance improvements have been implemented in the current FTP patches. Download and install the current General Release FTP patches.
I hope this helps.
--[[JamesHofmeister]]
-- Main.ChrisBartram - 18 Aug 2008