delayed ACK in TCP problem - TCP-IP

This is a discussion on delayed ACK in TCP problem - TCP-IP ; I'm running applications that send and receive timestamp as data to calculate latency between the client (32915) and the server (s_name_1). The client connect to the server and receive timestamp from the server and then, every 20 seconds, the server ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: delayed ACK in TCP problem

  1. delayed ACK in TCP problem

    I'm running applications that send and receive timestamp as data to
    calculate latency between the client (32915) and the server (s_name_1).
    The client connect to the server and receive timestamp from the server
    and then, every 20 seconds, the server send ping message (Len=18) to
    the client and the client reply ping ack message (Len=18) back to the
    server. The server sends 50 timestamps to the client every 50
    milliseconds.

    The problem is after the client reply ping ack message back to the
    server (see frame number 42014), the client will delay TCP ACK package
    that sent to the server for around 40 milliseconds (see diff time
    between frame number 42042 and 42041); therefore, the server need to
    wait for around 40 milliseconds before sending next timestamps to the
    client. Please see the output from the Ethereal below for more
    information:

    No. Time Source Destination
    Protocol Info
    42012 16.479992 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2636864 Ack=0 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=18 TSV=10219189 TSER=10219187
    42013 16.480010 172.20.11.177 172.20.11.177 TCP
    32915 > s_name_1 [ACK] Seq=0 Ack=2636882 Win=31232 Len=0 TSV=10219189
    TSER=10219189
    42014 16.480023 172.20.11.177 172.20.11.177 TCP
    32915 > s_name_1 [PSH, ACK] Seq=0 Ack=2636882 Win=31232 [TCP CHECKSUM
    INCORRECT] Len=18 TSV=10219189 TSER=10219189
    42015 16.480038 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2636882 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42016 16.480051 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2636946 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42017 16.480061 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637010 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42018 16.480073 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637074 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42019 16.480082 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637138 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42020 16.480092 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637202 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42021 16.480100 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637266 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42022 16.480110 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637330 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42023 16.480119 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637394 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42024 16.480130 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637458 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42025 16.480140 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637522 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42026 16.480149 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637586 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42027 16.480158 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637650 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42028 16.480167 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637714 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42029 16.480176 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637778 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42030 16.480186 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637842 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42031 16.480195 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637906 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42032 16.480205 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2637970 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42033 16.480214 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638034 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42034 16.480224 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638098 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42035 16.480233 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638162 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42036 16.480243 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638226 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42037 16.480277 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638290 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42038 16.480286 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638354 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42039 16.480295 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638418 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42040 16.480329 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638482 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42041 16.480338 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638546 Ack=18 Win=32767 [TCP CHECKSUM
    INCORRECT] Len=64 TSV=10219189 TSER=10219189
    42042 16.519968 172.20.11.177 172.20.11.177 TCP
    32915 > s_name_1 [ACK] Seq=18 Ack=2638610 Win=31232 Len=0 TSV=10219193
    TSER=10219189
    42043 16.519994 172.20.11.177 172.20.11.177 TCP
    s_name_1 > 32915 [PSH, ACK] Seq=2638610 Ack=18 Win=32767 Len=4608
    TSV=10219193 TSER=10219193

    I already used TCP_NODELAY option to disable Nagle's algorithm in TCP
    layer, however, the problem still happen; the server did not send the
    next timestamps to the client until it receive TCP ACK from the client.

    From, above situation, is it possible that the TCP_NODELAY option can
    not resolve the problem? If it is possible, how can I resolve the
    problem?

    PS. My applications are running on the AS 3.0, kernel 2.4.21-27.


  2. Re: delayed ACK in TCP problem


    Krit wrote:

    > I'm running applications that send and receive timestamp as data to
    > calculate latency between the client (32915) and the server (s_name_1).
    > The client connect to the server and receive timestamp from the server
    > and then, every 20 seconds, the server send ping message (Len=18) to
    > the client and the client reply ping ack message (Len=18) back to the
    > server. The server sends 50 timestamps to the client every 50
    > milliseconds.


    TCP was fundamentally not designed to provide constant latency for
    large numbers of small writes. You should be using UDP.

    DS


  3. Re: delayed ACK in TCP problem

    Krit wrote:
    > I already used TCP_NODELAY option to disable Nagle's algorithm in
    > TCP layer, however, the problem still happen; the server did not
    > send the next timestamps to the client until it receive TCP ACK from
    > the client.


    Did you set it at _both_ ends?

    Apart from the suggestion to use UDP (and the implicit "provide your
    own retransmissions") you might make sure that something like a
    botched Appropriate Byte Counting congestion control isn't in effect.
    Grep for "tcp" in sysctl -a and see if there is anything along those
    lines.

    Thankfully, netperf TCP_RR doesn't rely on one-way latency measures

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: delayed ACK in TCP problem

    Hey I think there is a special mode called TCP_QUICKACK , which take no delay after a arrival of the ping packet. You might like to go and find something about that

+ Reply to Thread