Jeff Kell ([log in to unmask]) wrote:
: 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?).
 
  - best that I know of is to use debug... not that user-friendly but doable.
    As you know, these are maintained on a per-connection basis and thus you'd
    have to locate the right tcp-connection to monitor.
 
: 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.
 
  - TCP on 3000 tries to use a tcp-window size of 65535 bytes (if the remote
    end supports that big window) and would typically use up all that.
    I've seen on ftp traces of large xfers that sometimes the remote side lags
    pretty badly in ack'ing the tcp packets - somewhere around 30+ kbytes
    behind.  This could happen with relatively slow networks regardless of
    the remote machine.  I wonder if the reason has something to do with
    TCP's "silly-window-syndrom" avoidance algorithms...  As said in the
    previous posting, I recall there being a bug in transport where TCP on
    HP3000 did not run as fast as it could because of some timer problem
    and sometimes did not re-transmit at all. [get the latest transport patch]
 
  - By default there is 256kBytes of buffer space allocated for transport.
    You can expand this up to 512kB.  If you're concerned about buffer space
    utilization, have a look in resource screens in nettool.net.sys
 
 
: 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).
 
  - TCP timers are configurable in NMMGR screen NETXPORT.GPROT.TCP and
    maybe what you're referring to is the "Retransmission Interval Lower Bound"
    field???
 
 
:-) Eero Laurila - HP CSY Networking lab, NS services.