

When there are multiple packet loss events, a chart of the "Bytes-in-Flight" value forms a sawtooth pattern with fast decreases and slow increases. The subsequent "gentle" ramp up (usually by one packet per RT) means that overall throughput suffers severely. When a sender detects packet loss it is supposed to "halve" its transmit window and then ramp up very slowly.Ī halving of bytes-per-round-trip or packets-per-RT results in a halving of throughput. It is some relatively small packet losses at various times which trigger the TCP "Congestion Avoidance" mechanism/algorithm. However, the reason for the slow transfer is actually quite basic and common. That is, missing from the trace file but were there in real life. Running out of ideas.Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of packets that weren't captured. Continuing to see the timeouts.Īnyone any suggestions of what to try? theres a couple of support notes on TCP retransmissions but nothing leading me to the answer here. Im running a RAC, I tried it on the SCAN and then forced it down the VIP, bypassing the SCAN. Internal or external firewalls not showing any drops. The listener log does not show the connection hitting it for the timeout event. A good start/accept port exchange would take 1-2 seconds max.

Im guessing its not as the client has opened many streams since it opened the start connection and port has closed at that stage. The return is not on the client pcap though.

If I search the firewall for the start on the port, I can see it make the start attempt, but it doesnt make the return for over 2 minutes. The external firewall is showing the start packet from the source client IP/port, I then have a 5 second timeout of no traffic that coincides with a 5 second command timeout in the program at which time data starts flowing again. Examining the PCAP for the timeout event, I track the TCP flow, I see it making the attempt out a source port, followed by 2 tcp retransmissions.

I set up a connection program that runs every 5 seconds. Windows client > external firewall > internal firewall > database Examining the PCAP in wireshark, I see tcp retransmission for the tcp flow at timeout event in a packet capture Getting a program intermittently timing out.
