tcpip equiv of tcp_deferred_ack_interval

[Jim Hintze]

we are having a issue with socket disconnects to asia from nyc. unix admin want us to adjust their equiv of tcp_deferred_ack_interval. I'm having trouble mapping unix parameters to VMS implementation. Any of the below close??

ia64 ovms 8.31h1 follows is what I have.

Thansk
Jim


USTBT2:SYSTEM> sysconfig -q inet
inet:
icmp_redirecttimeout = 0
icmp_rejectcodemask = 0
icmp_tcpseqcheck = 1
inifaddr_hsize = 32
ip_max_frag_index = 64
ipdefttl = 64
ipdirected_broadcast = 0
ipforwarding = 0
ipfragttl = 60
ipgateway = 0
ipport_userreserved = 65535
ipport_userreserved_min = 49152
ipqmaxlen = 2048
ipqs = 1
ipsendredirects = 1
ipsrcroute = 1
pmtu_decrease_intvl = 1200
pmtu_enabled = 1
pmtu_increase_intvl = 240
pmtu_rt_check_intvl = 20
subnetsarelocal = 1
tcbhashnum = 1
tcbhashsize = 512
tcbquicklisten = 1
tcp_compat_42 = 1
tcp_cwnd_segments = 2
tcp_dont_winscale = 0
tcp_keepalive_default = 0
tcp_keepcnt = 8
tcp_keepidle = 14400
tcp_keepinit = 150
tcp_keepintvl = 150
tcp_msl = 60
tcp_mssdflt = 536
tcpnodelack = 1
tcp_recvspace = 61440
tcp_rexmit_interval_min = 2
tcp_rexmtmax = 128
tcprexmtthresh = 3
tcp_rst_win = -1
tcp_rttdflt = 3
tcp_sendspace = 61440
tcp_syn_win = -1
tcp_ttl = 128
tcptwreorder = 0
tcp_urgent_42 = 1
udpcksum = 1
udp_recvspace = 42080
udp_sendspace = 9216
udp_ttl = 128
ovms_nobroadcastcheck = 0
ovms_printf_to_opcom = 1

[Duncan Morris]

Jim,

you may find this of interest

10.2.11 Disabling Delaying the Acknowledgment of TCP Data

The value of the inet subsystem attribute tcpnodelack determines
whether the system delays acknowledging TCP data. The default is 0,
which delays the acknowledgment of TCP data. Usually, the default is
adequate. However, for some connections (for example, loopback), the delay
can degrade performance.
You may be able to improve network performance by setting the value of
the tcpnodelack attribute to 1, which disables the acknowledgment delay.
However, this may adversely impact network bandwidth. Use the tcpdump
command to check for excessive delays.
See Section 4.4 for information about modifying kernel subsystem
attributes.

This is from the Tru64 System Configuration and tuning manual, and the VMS TCPIP implementation came from there.

Duncan

[Jim_McKinney]

Someone else may know otherwise, but I don't believe that HP's TCP/IP supports manipulation of a tcp_deferred_ack_interval attribute as do unix systems. If your application does not utilize keepalives you might consider enabling them - if you don't have the source code to do so you could force all connections to use keepalives via tcp_keepalive_default attribute which is shown with the default value of "off" in your post above.

> tcp_keepalive_default = 0

[rick jones]

I cannot claim any familiarity with the OpenVMS TCP/IP code, but based on asking about something akin to the tcp_deferred_ack_interval, unless the other side of the connection has an unusually short minimum TCP retransmission timeout, I fail to see how even enabling immediate ACKs would affect a problem with connection failures.

Likely as not, the path from nyc to asia is beset with packet loss problems, and unless the OpenVMS TCP/IP stack has a badly broken ACK avoidance heuristic, short of additional data, I'd say someone is desparately grasping at straws.

These however,

tcp_recvspace = 61440
tcp_sendspace = 61440

look awfully low in the context of connections running between NYC and Asia - it still does not a priori have much of anything to do with actual connection robustness, but the attachment I've put here (despite having a linux focus) describes why a WAN connection may need a rather larger TCP window.

[rick jones]

Here is the attachment :)

[Cass Witkowski]

None of the parameters above look like they change the delay ack time. I would advise against changing it since it could have negative performance impacts on your network.

Can you explain more about the socket disconnects?

I'm assuming you have a TCP/IP link between two servers. This link should be up all the time.



1) How often do you get disconnects?
2) Is there always traffic on the link or do you have times when the link is idle?
3) Do you see packet retransmits?
4) Is the connection being closed using the TCP/IP closing handshake of FIN ACK FIN ACK?
5) Is this connection going through a firewall?
6) Are either of the servers using DHCP for IP addresses?