Hello All @ 3000-l,

RE:  FTP Transmission Problem & Inexplicable interface discards?

Sorry I did not reply earlier.. I guess I am happy in these times to say my
job is keeping me busy.

>>Every night we transmit a 1.5 gb file from our Hp System locally to a
>>HP system 700 miles away.  Up until a few weeks ago the FTP was taking
>>aprox. 3 hours.  Now the FTP takes anywhere from 12 hours or more to
>>complete, sometimes it does not complete at all.   Thinking the problem
>>was with our cisco switches, we had a cisco engineer check out the
>>problem.   The engineer is recommending we hard code the speed and duplex
>>on each system.

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.

Regards,
James Hofmeister
Email: <first>.<last>@hp.com
Hewlett Packard - Global Solutions Engineering (WTEC).
P.S. My Ideals are my own, not necessarily my employers.

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