Question about tcp_keepalive_interval (user sessions dropping)

[JDR45]

Thanks for the links to the white papers.  WIll give them a read.  This server barely gets any use- 18 users max- which is another reason why I don't get why the remote user sessions drop..  It isn't from a heavy load.

Will keep track of netstat -s and keep an eye on the certain interesting numbers you mentioned.

Here's a fresh one from today, June 24-

------------------------------------------------------------------------------------------------------------------------

tcp:

4546858 packets sent

3285808 data packets (807571499 bytes)

39086 data packets (5025188 bytes) retransmitted

1261252 ack-only packets (1184862 delayed)

0 URG only packets

0 window probe packets

2 window update packets

452435 control packets

4127369 packets received

2651991 acks (for 810062267 bytes)

1651 duplicate acks

0 acks for unsent data

2323447 packets (237362168 bytes) received in-sequence

1 completely duplicate packet (119 bytes)

89 packets with some dup, data (33129 bytes duped)

8339 out of order packets (5251771 bytes)

27 packets (3284241333 bytes) of data after window

0 window probes

17433 window update packets

18 packets received after close

7 segments discarded for bad checksum

0 bad TCP segments dropped due to state change

60942 connection requests

17996 connection accepts

78938 connections established (including accepts)

125648 connections closed (including 46724 drops)

45686 embryonic connections dropped

2480824 segments updated rtt (of 2480824 attempts)

216572 retransmit timeouts

45582 connections dropped by rexmit timeout

0 persist timeouts

162795 keepalive timeouts

156413 keepalive probes sent

149 connections dropped by keepalive

0 connect requests dropped due to full queue

2159 connect requests dropped due to no listener

0 suspect connect requests dropped due to aging

0 suspect connect requests dropped due to rate

udp:

0 incomplete headers

0 bad checksums

0 socket overflows

ip:

4405083 total packets received

0 bad IP headers

0 fragments received

0 fragments dropped (dup or out of space)

0 fragments dropped after timeout

0 packets forwarded

0 packets not forwardable

icmp:

79 calls to generate an ICMP error message

0 ICMP messages dropped

Output histogram:

echo reply: 78

destination unreachable: 1

source quench: 0

routing redirect: 0

echo: 0

time exceeded: 0

parameter problem: 0

time stamp: 0

time stamp reply: 0

address mask request: 0

address mask reply: 0

0 bad ICMP messages

Input histogram:

echo reply: 56777

destination unreachable: 14

source quench: 0

routing redirect: 0

echo: 78

time exceeded: 0

parameter problem: 0

time stamp request: 0

time stamp reply: 0

address mask request: 0

address mask reply: 0

78 responses sent

igmp:

0 messages received

0 messages received with too few bytes

0 messages received with bad checksum

0 membership queries received

0 membership queries received with incorrect fields(s)

0 membership reports received

0 membership reports received with incorrect field(s)

0 membership reports received for groups to which this host belongs

0 membership reports sent

[donna hofmeister]

I don't like that you have tcp checksums....but the number is so low that it's likely the "frankengram" scenario....

Your re-transmit rate is about 4% which may be enough for this application to have issues. I still urge you to raise this with your networking team. Perhaps they can do some tuning on their side.....

[JDR45]

I think the problem is on the network at the remote location, the user's PC, or something with the Hummingbird Host Explorer software.  I just don't see anything on the Unix server I can fix to help with this.

Learned a lot about netstat and ndd though, so thanks everyone!

[akio_kabutogi]

https://confluence.eits.uga.edu/display/HDSH/Hummingbird+Issues

has the description to set up keepalive signal to be sent from the client side under "Keep Alive Signal" section. This would be the perfect solution, I suppose, though tcp_keepalive_interval can be set upto 10*24*3600000.

If this action is set by the Hmmingbird side, then, you'll never get the session timed out.