Thanks Craig for all the help and suggestions so far. We reduced our TCP settings by 25% last week and so far it seems that we are encountering less problems. However, the settings that James has listed below are way below what we have them set at. Oddly though when you are in the TCP screen in NMMGR and read the help for the parameters/settings, they suggest increasing them if you are having problems. Our settings were high(er) and were probably in response to this type of problem in the past.
The write up below was very helpful and informative though.
wilson
From: Craig Lalley [mailto:[log in to unmask]]
Sent: Monday, November 10, 2008 12:54 PM
To: Wong, Wilson
Cc: [log in to unmask]
Subject: RE: User Disconnect Issues
Wilson,
James Hoffmeister did a great write up on this in Dec. 2001... I don't know how to link to it...
I hope James is not offended by it, here is a cut and paste...
-Craig
Subject:
QCTerm And Disconnects
From:
"HOFMEISTER,JAMES (HP-USA,ex1)" <[log in to unmask]>
Reply-To:
HOFMEISTER,JAMES (HP-USA,ex1)
Date:
Sat, 1 Dec 2001 02:07:21 -0500
Content-Type:
text/plain
Parts/Attachments:
[http://raven.utc.edu/archives/images/b-paperclip.gif]
text/plain<http://raven.utc.edu/cgi-bin/WA.EXE?A3=ind0112A&L=HP3000-L&E=0&P=2283&B=--&T=text%2Fplain;%20charset=iso-8859-1> (253 lines)
Hello Jeff & @ 3000-l,
Re: QCTerm And Disconnects
OOPS's I intended on leaving the "Initial Retransmission Interval" at
the default... but copied the recommendation off a friends system
since I had already clobbered mine.
[4 ] Initial Retransmission Interval (Secs)
Either [2] or [4] will work... [4/5] is a better startup value for a
"really" poor quality internet link.
how this works...
I configured my system for:
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4] Initial Retransmission Interval (Secs)
[ 6] Maximum Retransmissions per Packet
Lets assume we have a network problem "directly" following the
initial connection setup SYN/SYN-ACK/ACK. This is really the only
time the "Initial Retransmission Interval" comes into play.
With the configuration above a packet will be
retransmitted 6 times
with an increment of 4 seconds as follows:
TCP Packet sent...
no ACK response received from remote
4 seconds first retransmission of packet sent
no ACK response received from remote
8 seconds second retransmission of packet is sent (total of 12 seconds)
no ACK response received from remote
16 seconds third retransmission of packet is sent (total of 28 seconds)
no ACK response received from remote
32 seconds fourth retransmission of packet is sent (total of 60 seconds)
no ACK response received from remote
64 seconds fifth retransmission of packet is sent (total of 124 seconds)
no ACK response received from remote
128 seconds sixth retransmission of packet is NOT sent (252 seconds)
The TCP connection is terminated (252 seconds)
Note: The sixth retransmission of packet is
NOT sent since 252 exceeds
the "Maximum Time to Wait For Remote Response" of 180 seconds.
The packet has been sent once and retransmitted 5 times and we have not
received an acknowledge response from the remote host in 252 seconds. The
TCP connection is terminated.
==========
Now once a connection is established and a few packets have exchanged
between the local and remote host the "Retransmission Interval" becomes
a computed value known as the "T_RTX_TIME" (the computation for this
value is documented in the TCP RFC's and other network reference
manuals).
I configured my system for:
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4] Initial Retransmission Interval (Secs)
[ 6] Maximum Retransmissions per Packet
If the network connection between the local and remote host is
functioning and high speed the
value of T_RTX_TIME will move from the
Initial Retransmission Interval [4] towards the Retransmission Interval
Lower Bound [1] and may be less than this value.
Note: in the case where the T_RTX_TIME is less than the Retransmission
Interval Lower Bound [1], then the Retransmission Interval Lower
Bound will be used. [1] is the lowest possible value on the hp-e3k, so
on a good quality high speed link the "Retransmission Interval" used will
typically be Retransmission Interval Lower Bound[1].
If the network connection between the local and remote host is poor,
busy or low speed the value of T_RTX_TIME will move to a value greater
than the Initial Retransmission Interval [4].
I have found on the hp-e3k that the computed T_RTX_TIME moves very quickly
from the "Initial Retransmission Interval" to a value lower than the
"Retransmission Interval Lower Bound" within the amount of network traffic
for a logon
to the hp-e3k.
Here is the output of a debug macro executed against a TELNET logon to the
":" prompt.
$3f0 ($41) nmdebug > nstcp_cons
TCP Connections
connection count = $10 = #16
...
Index Connection State Link Src IP Dst IP SSap DSap NWTM
9 $13a.1600 4.4 00050000 0f2c3033 0f7216a2 0017 05c0
$b3.4638
I can tell this is my Telnet connection since the Source Sap is $17 = #23
which is the telnet port.
$3f2 ($41) nmdebug > jh_nstcp_con_time $13a.1600
------------------------------------------------------------
[Yes] Checksum Enabled (Y For Yes, N For No)
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4] Initial Retransmission Interval (Secs)
[ 6] Maximum Retransmissions per
Packet
------------------------------------------------------------
T_PROTOCOL_STATE : ESTABLISHED
T_IPC_STATE : IPC_ESTABLISHED
T_SRT_TIME : $7a ( 1.000 Seconds)
T_SRT_MDEV : $18 ( 0.196 Seconds)
T_RTX_TIME : $4c ( 0.622 Seconds) <<--
T_STATS.INBOUND_STATS.USER_PKTS : 45 <<--
T_STATS.OUTBOUND_STATS.USER_PKTS : 39 <<--
T_STATS.INBOUND_STATS.CKSUM_ERROR : 0
T_STATS.OUTBOUND_STATS.RTX : 0
This macro displays the "T_RTX_TIME" which is less than the
configured "Retransmission Interval Lower Bound" of [1]. it is also
interesting to see that 45 inbound packets and 39 outbound
packets
have been exchanged to complete a logon with Telnet to the hp-e3k.
-----
I performed the same test with NS-VT VTSERVER and here are the results:
$3fc ($41) nmdebug > nstcp_cons
TCP Connections
connection count = $3 = #3
Index Connection State Link Src IP Dst IP SSap DSap NWTM
3 $13a.2940 4.4 00050000 0f2c3033 0f7216a2 0622 0656
$b3.4638
I can tell this is my Telnet connection since the Source Sap is $622 = #1570
which is the Ns-services VT port.
$3fd ($41) nmdebug > jh_nstcp_con_time $13a.2940
------------------------------------------------------------
[Yes] Checksum Enabled (Y For Yes, N For No)
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4] Initial Retransmission Interval (Secs)
[ 6]
Maximum Retransmissions per Packet
------------------------------------------------------------
T_PROTOCOL_STATE : ESTABLISHED
T_IPC_STATE : IPC_ESTABLISHED
T_SRT_TIME : $4a ( 0.606 Seconds)
T_SRT_MDEV : $19 ( 0.204 Seconds)
T_RTX_TIME : $46 ( 0.573 Seconds) <<--
T_STATS.INBOUND_STATS.USER_PKTS : 8 <<--
T_STATS.OUTBOUND_STATS.USER_PKTS : 10 <<--
T_STATS.INBOUND_STATS.CKSUM_ERROR : 0
T_STATS.OUTBOUND_STATS.RTX : 0
This macro displays the "T_RTX_TIME" which is less than the
configured "Retransmission Interval Lower Bound" of [1]. it is also
interesting to see that 8 inbound packets and
10 outbound packets
have been exchanged to complete a logon with NS-VT to the hp-e3k.
In both the cases of Telnet and NS-VT the T_RTX_TIME is less than
the Retransmission Interval Lower Bound [1] (Secs) by the time a
logon is complete.
-----
Now with the configuration above the T_RTX_TIME is less than the
"Retransmission Interval Lower Bound" [1] so a packet will be
retransmitted at the "Retransmission Interval" of [1].
With the configuration above a packet will be retransmitted 6 times
with an increment of 1 seconds as follows:
TCP Packet sent...
no ACK response received from remote
1 seconds first retransmission of packet sent
no ACK response received from remote
2 seconds second retransmission of packet is sent (total of 3 seconds)
no ACK response received from remote
4 seconds third retransmission of packet is sent (total of 7
seconds)
no ACK response received from remote
8 seconds fourth retransmission of packet is sent (total of 15 seconds)
no ACK response received from remote
16 seconds fifth retransmission of packet is sent (total of 31 seconds)
no ACK response received from remote
32 seconds sixth retransmission of packet is sent (total of 62 seconds)
no ACK response received from remote
The TCP connection is terminated (126 seconds)
The packet has been sent once and retransmitted 6 times and we have not
received an acknowledge response from the remote host in 126 seconds. The
TCP connection is terminated.
Sorry for the confusion... I recommend:
============================================================
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4]
Initial Retransmission Interval (Secs)
[ 6] Maximum Retransmissions per Packet
============================================================
If I still have connectivity problems with this configuration, then my
next action is to look at the NM logfiles to determine what is actually
happening before I alter the timers further.
Just for fun... I did a logon and :listf @[log in to unmask]@,3 with a WRQ VT-3K
connection to my hp-e3k a-class over a marginal quality isdn link and
here is what I see:
$407 ($41) nmdebug > jh_nstcp_con_time $13a.2940
------------------------------------------------------------
[Yes] Checksum Enabled (Y For Yes, N For No)
[ 1] Retransmission Interval Lower Bound (Secs)
[ 180] Maximum Time to Wait For Remote Response (Sec)
[ 4] Initial Retransmission Interval (Secs)
[ 6] Maximum Retransmissions per
Packet
------------------------------------------------------------
T_PROTOCOL_STATE : ESTABLISHED
T_IPC_STATE : IPC_ESTABLISHED
T_SRT_TIME : $61 ( 0.795 Seconds)
T_SRT_MDEV : $4 ( 0.032 Seconds)
T_RTX_TIME : $49 ( 0.598 Seconds) <<--
T_STATS.INBOUND_STATS.USER_PKTS : 20
T_STATS.OUTBOUND_STATS.USER_PKTS : 4796
T_STATS.INBOUND_STATS.CKSUM_ERROR : 29 <<--
T_STATS.OUTBOUND_STATS.RTX : 115 <<--
Hmmm... 29 TCP Checksum errors and 115 TCP retransmissions. This really
is a poor quality link. I ran the same test with Telnet and really
saw little difference.
I hope this
helps.
Regards,
James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
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 *
|
