Socket problems after TCP/IP Eco 6 patch

[Bernhard von Gunten]

Labadie: Find the output in the attachement.

(Sadly, only from today.)

[Ian Miller.]

IIRC the change to tcp_keepidle = 14400
has caused some people problems. The previous value was smaller.

[labadie_1]

The previous value was 150 or 3600 I think.

I have a system with Eco 5, the sysconfig settings are exactly the same, so the change was in a more old ECO I suspect.

And you said you came from ECO 2.

By the way, nothing suspect in your tcpip sh inetcb/stat.

[labadie_1]

Oh, the unit is the half second, so 7200 means one hour.

[Bernhard von Gunten]

EdgarZamora:

Linger definitely has been an issue between the workers and the daemon lately. Still facing problems between the daemon and the outside world. But you're right, any Eco Patch between 2 and 6 could have "hit" us there.

How did you deal with the issue?

[STEPHEN CONWAY_1]

Just guessing here, but this could be a problem with retransmissions. You may have to take some network traces of the traffic between the two systems and see if there is a lot of retransmit traffic. If there is then we have a patch for you. If you have the "perf" symbol tables loaded, you can check the retransmit stats with:

SDA> FORMAT/TY=TCPSTAT TCPSTAT

Steve

[EdgarZamora]

Bernhard,

In my previous job, the linger problem was due to TCPIP engineering making a change to adhere more strictly to whatever RFC it was that was related to the function. I don't have my notes handy until I get home tonite.
The user eventually had to change their application code to take out the linger option. That was their solution.

I think this change was made earlier than ECO 5. Maybe 4 or 3 but I can't verify right now.

[Bernhard von Gunten]

EdgarZamora:

Our linger to the outside world is set to 1 second today. But the day the problems started (and the Eco patch has been installed) it was set to 0. No difference though.

Anybody:

Today we're doing some load tests on the pre-production systems.

This is the output of $ ucx netstat -p tcp


tcp:
63998289 packets sent
59713016 data packets (3480843508 bytes)
463060 data packets (675952321 bytes) retransmitted
2230472 ack-only packets (182444 delayed)
0 URG only packets
38 window probe packets
743606 window update packets
848097 control packets
36486319 packets received
23771333 acks (for 3482439193 bytes)
5922635 duplicate acks
0 acks for unsent data
2499866 packets (1952310313 bytes) received in-sequence
745 completely duplicate packets (35209 bytes)
1 packet with some duplicate data (88 bytes duped)
731786 out-of-order packets (70761044 bytes)
0 packets (0 bytes) of data after window
0 window probes
3757913 window update packets
16 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet was too short
361202 connection requests
620870 connection accepts
982071 connections established (including accepts)
981706 connections closed (including 31 drops)
1 embryonic connection dropped
7354000 segments updated rtt (of 7571306 attempts)
164 retransmit timeouts
0 connections dropped by rexmit timeout
40 persist timeouts
71 keepalive timeouts
28 keepalive probes sent
1 connection dropped by keepalive

Any comments ?

[Bernhard von Gunten]

Hello all,

thank you for your support. It was impressive to watch how fast people tried to help here and how important communities are for all of us.

I close the thread, as further investigations have to be done on Tru64 side.

If you're interested in it, i've just opened a thread in the (evil hehe) Unix forum.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1085736

Thanks & Greetings from Switzerland,

Bernhard