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.

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

Krit <krit_kasemosoth@hotmail.com> 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...