Connection Analysis
|
SQMD01: TCP is waiting too long for data.
In the normal course of moving data between server and client the maximum TCP delay waiting for data to arrive should not exceed (by much) the difference between the trip time and the time taken for the client to read the full data window sent as measured at the slowest capacity speed of the connection end-to-end (the slowest part of the connection is usually the clients connection speed but this may not always be the case). When larger delays are recorded in receiving data it would normally cause the data QoS flow measurement to drop depending on the increase size of the delay. This occurs because in a window of time less data is received than other equal windows of time. If the QoS is high then it may indicate that there are several evenly distributed TCP delays which is a sign of regulation issues rather than congestion issues. As an practical real life example of this imagine cars travelling along on a highway. If there is heavy congestion caused by an accident then the traffic flow would drop sharply after the accident point until such time as the blockage is cleared. Conversely, if there is a set of traffic lights turning red for 1 minute every 3 minutes then there will be a traffic delay pattern that repeats consistently over the time window. In the latter example data flow QoS is quite likely to be higher because each time window measured has the same delay impact. In the former example this will not be the case because the event that causes the delay is unlikely to reoccur once cleared. If the test graph shows a data spike at the time of the delay that appears to exceed the speed of the connection then this is a good indication of a data loss event. If there is no spike then it is a good sign of possible duplicate data transmissions. Need more help or have questions, please contact us. |