HP Unix TCP IP stack tuning

[Sachin Sontakke]

Hi Gurus,

I have came across one issue here.
My server is HP 9000 with HP-UX 11i loaded.
It has a business application running for a manufacturing company. In this company few workers use RF devices (bar code scanners) to scan data from labels and update that data to database. Database is on my HP-UX server.
Those RF devices are not physically connected to network. They send wireless signals to some access points which route data to server.
Many times those devices just hung up as they loose connection to server and that creates problem.
I wanted to ask how to configure my TCP/IP stack parameters so that server will never loose connection with RF devices.
I tried "ndd -h"... it gave me so many parameters.
Can anyone tell me which parameter change can help in this situation?

- Thanks in advance.

[RAC_1]

How do the access point sends the data to the server?? Is server listening on some port for that?? Does it use tcp or udp??

Depending upon that you may look at tcp alive interval, syn_wait_2 inetrval etc.

ndd -h supported|grep tcp
ndd -h supported|grep udp

The help specific to certain ndd parameter can be displayed as follows. This is self explainatory and should give some idea on which parameters should be tuned.

ndd -h tcp_keep_alive

In addition to that do you have any setting on access point which can control timeout setting? or similar setting???

Keep in mond that a shobliy written application can hang the port. Also if you have firewall between, then check that also.

Anil

[rick jones]

"never" lose connection? that isn't possible. by default, the HP-UX 11.X TCP stack will wait for 10 minutes for a packet it has sent to be retransmitted - that is tcp_ip_abort_interval. if you think you have "normal" service interruptsions in your RF net that would last that long or longer I _suppose_ you could increase the value.

it might be good to further investigate those losses you are seeing to see what might be the root cause - packet traces and the like might be helpful. examination of netstat -p tcp statistics might be good too

[Sachin Sontakke]

I am attaching following o/p of netstat command :

# netstat -p tcp

tcp:
228446433 packets sent
220211230 data packets (1865594610 bytes)
4744593 data packets (1016108920 bytes) retransmitted
8235635 ack-only packets (4207961 delayed)
0 URG only packets
1055910 window probe packets
830 window update packets
5373930 control packets
191757304 packets received
128753295 acks (for 1867295226 bytes)
21437724 duplicate acks
22 acks for unsent data
56863810 packets (3083889855 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
636 packets with some dup. data (36473 bytes duped)
957895 out-of-order packets (1284521562 bytes)
77 packets (1439228958 bytes) of data after window
2903 window probes
2261264 window update packets
362 packets received after close
5086 segments discarded for bad checksum
0 bad TCP segments dropped due to state change
19727026 connection requests
1519805 connection accepts
21246831 connections established (including accepts)
21811812 connections closed (including 565321 drops)
561001 embryonic connections dropped
117046300 segments updated rtt (of 117046300 attempts)
416463 retransmit timeouts
54308 connections dropped by rexmit timeout
1055910 persist timeouts
255941 keepalive timeouts
254789 keepalive probes sent
1882 connections dropped by keepalive
0 connect requests dropped due to full queue
36846 connect requests dropped due to no listener


Is anything visible from this which will help my case??

Here I think two different scenarios to be checked : first to see if RF device failing to talk to access points and second my HP-UX server is having some communication problem with access points.

Please help me find solution on this.

Thanks for your help so far.

- Sachin

[Dave Olker]

I just attended Paul Comstock's HP World session where he discussed several ndd tunables. One he mentioned, that I admit I'd never heard of nor played with, is "tcp_smoothed_rtt". Paul said this parameter can influence networks with volatile delay behaviors, such as cellular or sattelite links.

It sounds like your RF network may fall into this volatile category as well, so perhaps "tcp_smoothed_rtt" might be an avenue to explore.

Regards,

Dave

[rick jones]

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt

might be useful. Also "beforeafter" from ftp://ftp.cup.hp.com/dist/networking/tools/ so you can take two snapshots of netstat -p tcp over a measured interval and take the difference between them:

$ netstat -p tcp > before
$ sleep
$ netstat -p tcp > after
$ beforeafter before after > delta
$ more delta

However, it does look like you have a rather lossy network - the data packets retransmitted divided by the data packets sent is a fairly high percentage. The retransmission timeouts is rather lower, which is good - it means the retransmits are generally happening quickly.

If your RF devices actually connect via telnet, you may want to consider using the "TCP_DELAY" option of telnet to re-enabled the Nagle algorithm and minimize the number of small segments tossed at your RF devices.

I see there are some connections dropped thansk to retransmissions - basically, that many times, an RF device did not respond to the HP-UX system for at least 10 minutes.

One way to check if the aforementioned tcp_smooth_rtt would help would be to take a packet trace and see that there were "spurrious" retransmissions - that is retransmissions that happened simply because the RTT (round-trip-time) became very large very quickly.

One other consideration is to check - does the RF kit have its own retransmission mechanisms going? If so, you may want to consider changing tcp_rexmit_interval_min to take that into account - if the RF kit might take up to 1 second to do its thing you may not want tcp_rexmit_interval_min lower than one second plus some fudge-factor.