On Tue, 11 Apr 1995 14:18:00 PDT Williams, Pete - Prog Analyst said:
>Since putting our HP on the network a month ago, we have begun implementing
>some automated FTP transfers from a DG Aviion to and from our HP.  A problem
>occurs when data is leaving the HP, but does not occur when it is arriving.
> The problem is transfer time.  A process putting a 9 meg file to the HP
>might take 70 - 80 seconds, while getting the exact same file might take
>18-23 minutes.  We have checked the path, and the packets are going to and
>coming from the HP across the same paths.  We haven't gotten into playing
>with all the different configuration options yet, but we will be this
>afternoon.
 
If you have a *definite* directional problem (remote client has slow gets and
fast puts, or local client has slow puts and fast gets) you've probably got a
buffer or timer problem.  The HP3000 is tuned to fast local network response
in general, but that can go downhill in this situation.  If the RTT (Round
Trip Time) measured is sizeable (say 500 msec or higher) I've seen this type
of behavior.  I don't know exactly how to monitor this closely on the 3000
itself (there may be tools?).
 
By definition, you can have several packets "in transit" since TCP provides
sequence number acknowledgement.  Most implementations allow several packets
to be in transit, limited by a constant or the availability of buffers (you
can't free a buffer until it has been ACKed).  Consequently, the 3000 can
receive packets about as fast as you care to send them, if the sender allows
multiple packets in transit.  However, the 3000 doesn't appear to transmit
packets with equal ease, so I would guess at a buffer limitation or an upper
bound on the number of unACKed packets allowed in transit.
 
This is largely theoretical :-)  Perhaps an HP Networking SE can provide
additional details or specifics.  You do have some control over buffering
in NMMGR (as I recall) but I don't know about timers (there is also a timeout
threshold as to how long to wait before receiving an expected ACK).
 
[\] Jeff Kell, [log in to unmask]