This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

why is there a big delay between ACK and [PSH,ACK] segment

0
1

Hello, In my wireshark capture I am seeing a delay of approximately 3 seconds between ACK segment and [PSH,ACK] having the same sequence numbers. I am trying to understand why is this delay of the 3 seconds because our application cannot tolerate such big delays. However, elsewhere in the wireshark trace I have seen a delays little above 1 second between the ACK and [PSH,ACK] segments. Pasting the wireshark trace here.

alt text

As you can see from the above the picture frame 3140 and frame 3146 are having the same sequence number, frame 3146 gets transmitted after approx. 1 second. In between those frames there were retransmissions whose RTOs in the wireshark was 9 seconds. I was wondering initially these retransmissions would affect the connection between 192.168.21.31 and 192.168.21.41. I have seen a similar packets exchange except this time between the ACK and [PSH,ACK] of the same sequence number there is a delay of 3 seconds. Attached is the picture of the delay of 3 seconds.

alt text

From the above picture frame 4303 is having the same sequence number as the frame 4300. Could the retransmissions in between the frames 4300 and 4303 can cause this delay. If so, why there was no delay in the first picture between frames 3140 and 3146. Are the retransmissions between the frames affecting the RTO between 192.168.21.31 and 192.168.21.41.?

192.168.21.31  - Linux box
192.168.21.41  - Windows 7 PC
Can experts help me understand this problem.

Thank you so much DP

asked 02 Feb '15, 17:40

DPnetwork's gravatar image

DPnetwork
1121
accept rate: 0%

edited 03 Feb '15, 02:34

Jaap's gravatar image

Jaap ♦
11.7k16101


One Answer:

0

It seems you are capturing on the windows PC (192.168.21.41) or at least on a span port copying the traffic from the port on which this PC is attached.

If this is true, then the only conclusion you can draw from the captured data is that the process responsible for this connection is taking 1s (or 3s in the second example) to respond. Either the PC is very busy and the process does not get enough priority or the process needs time to come up with the response. Are there any secondary connections like a DB connection? Or is there much disk IO involved?

answered 03 Feb '15, 02:40

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thanks for the response SYN-bit.

There is no DB connection in this application. I am still not ruling out CPU being busy because of disk IO or the application is waiting for something. the 1 second or 3 second delay happened on the Linux(192.168.21.31) not on the Windows PC(192.168.21.41).

These are the question I have. a) Did the 1 second delay in frame 3146 caused the increase in delay in frame 4303? I am just wondering if this 1 second delay is called the RTO between 192.168.21.31 and 192.168.21.41. if so, did the RTO bumped in the frame 4300. Because the delays I understand change 1, 3, 6,12,24... b) Whenever this delays happened there will always be TCP retransmissions like frame 4301 in second case also frame 3141, 3143 in second case whos RTOs are like 8 or 9 seconds. I am just wondering whether the RTOs in the retransmissions affected the RTO between 192.xx.xx.31 and 192.xx.xx.41 connection. I read somewhere RTOs vary between each TCP connection, so if so it should not. I just want to confirm. Again I will look into if the CPU being busy will cause this problem. But, I want to understand if this is caused from the network behavior.

Thanks again. DineshP

(03 Feb '15, 10:23) DPnetwork