TCP Ack Too long

[rmnp0829]

Does anyone have a general recommendation for errors that have to do with TCP ack too long? I am generating errors for a particular service port 1090

4/23/2002 | 09:26:16.409 |<1ms Minor | Ack Too Long (213ms)| TCP: [172.16.100.63] - [172.16.111.174] Port 1090 - 1923

Users are complaining that the application is slow and are the blaming the network but the other TCP applications works fine such as ftp and http.

 

[fortunat]

You might want to take a closer look at that trace to see if the reponses are always greater than 200 ms. You may be looking at TCP's delayed ACK in action. LEt me know what you find out. 'Making things work better; bit by bit.'

 

[jamesgarlick]

how much information is being passed? bytes and frames? over how much time. look close into the trace file.

 

[ziekenhuis]

I have the same problem, can anybody tell me how this problem is solved ? Currently averybody is blaming the network, however i'm nor sure that's where the problem is.

 

[jacob200]

Like some of the other guys have said,
1) Do a filter on this whole conversation.
2) Are there lots of long acks (more than 200ms))
3) Check every hop between the two endpoints for errors, especially crc and frame errors on the wan links.

How far apart are the two endpoints? For example, if client sends a request to the web server, does the web server hand this off to a middleware server and then possibly a backend server(db server). This could be where most of the latency is. Delayed or Long Acks are very common and usually are not a fault of the network. Give me some more info. Thanks

 

[mpennac]

One problem with most protocol analyzers is that they set the Long ACK symptom to 200ms. I have found that Microsoft as well as some other vendors will wait the full 200ms before sending an ACK in response to a data packet.

This behavior is not a problem as long as the sending device does not have more data to send and is waiting for the ACK before sending it. I have started increasing the Long ACK symptom time to 250 ms and seeing how many Long ACK symptoms I still get.

As with all problems it is important to look at the flow of the traffic before you get too hung up on a single problem. If the sender is not waiting on that Long ACK to send more data, there is not problem, but instead it is the way that a vendor has chosen to implement the delayed ACK functionality. If the sender is waiting on the ACK to send more data, then you have got a real problem to dig into.

Look at the delta time between the Long ACK and the next data packet from the device receiving the ACK. If this delta time is short, problem. If it is long, no problem. Make sure you filter on the port number so you know that you are looking at the same conversation. Two devices can have more than one conversation going on at a time and this can confuse analysis.

mpennac
mike@networkprotocolspecialists.com