search

DD1984 / sockperf

Automatically exported from code.google.com/p/sockperf
Other
1 stars 0 forks source link

Sockperf with playback: reply for the very last packet(s) is lost #16

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1.Host1: LD_PRELOAD=libvma.so sockperf server -i <MC-group>
2. Host2: LD_PRELOAD=libvma.so sockperf playback -i <MC-group>  --data-file 
/tmp/playback --reply-every=1 
3. The playback contain:

0.510550, 12
0.510651, 12
0.510790, 12
0.510907, 12
1.511156, 12
1.511290, 12
1.555555, 32
1.555566, 32
2.555555, 32
3.666666, 12
15.55555, 64
20.44444, 64
#-- end of file --

What is the expected output? What do you see instead?

playback file should load successfully. Send/received should be 12

Actual results: SentMessages=12; ReceiveMessages=11

Please use labels and text to provide additional information.

Original issue reported on code.google.com by shiri...@gmail.com on 3 Apr 2011 at 3:48

GoogleCodeExporter commented 9 years ago 
Avner,
under-load and playback modes have different threads for send and receive as a 
result in usual case SentMessages and ReceiveMessages statistics are not equal.
Could you clarify if setting --reply-every as 1 for these modes should change 
their algorithm to ping-pong i.e. do send and receive in the same thread?

Original comment by igor.ivanov@itseez.com on 5 Apr 2011 at 2:38

GoogleCodeExporter commented 9 years ago 
No.  this is not reason that we'll change to ping-pong (the same as regular ul 
with --reply-every=1).  Anyhow, it is not correct to use --reply-every=1.

I believe you only need to wait short time (say 20 milliseconds) after sending 
last pb packet for its response.  Isn't it?

Original comment by avne...@gmail.com on 5 Apr 2011 at 3:04

GoogleCodeExporter commented 9 years ago 
More common question:
Currently, sockperf does not guarantee getting all reply packets inheriting 
legacy behaivour. So it is admissible case when a client sends packet with 
ping-pong flag, interrupted by timer sets status as exit (in case playback 
simply sets status exit) and does not wait for relply.
Should we stay on this manner or change requirements to the tool?

Original comment by igor.ivanov@itseez.com on 6 Apr 2011 at 5:31

GoogleCodeExporter commented 9 years ago 
No need to change requirements, I added the 20milliseconds wait after sending 
last packet.  This should be more than enough for receiver thread to receive 
last replies.  

Igor, Please test it and let me know if it fixed the issue!

(PS, I agree that reply of last packet is not important in real tests)

Original comment by avne...@gmail.com on 6 Apr 2011 at 6:18

GoogleCodeExporter commented 9 years ago 
I think that this changes can bring confusion for expected behavior of playback 
and under-load modes. We say that playback mode is based under-load algorithm 
but these changes make it slightly differ (mostly it could be imperceptible but 
can confuse as fake effect). Moreover there is possibility that wait time is 
not insufficient.
The same question can be raised for ping-pong mode too.
So I think we need to set clear requirements for this case for all modes and 
adapt code to these requirements if it is needed.
What do you think?

Original comment by igor.ivanov@itseez.com on 6 Apr 2011 at 6:41

GoogleCodeExporter commented 9 years ago 
i don't agree with you.
please let me know if this solved the issue in playback!

Original comment by avne...@gmail.com on 6 Apr 2011 at 9:00

GoogleCodeExporter commented 9 years ago 
Checked with r43 (w/o effect):

$~/prj/sockperf_r43/inst/bin/sockperf sr -i 10.10.10.51 -p 12345
sockperf:  == version #2.5.43 ==
sockperf: [SERVER] listen on:
[ 0] IP = 10.10.10.51     PORT = 12345 # UDP
sockperf: Warmup stage (sending a few dummy packets)...
sockperf: [tid 17130] using recvfrom() to block on socket(s)

$~/prj/sockperf_r43/inst/bin/sockperf pb -i 10.10.10.51 -p 12345 
--reply-every=1 --data-file=issue16.txt
sockperf:  == version #2.5.43 ==
sockperf[CLIENT] send on:sockperf: using recvfrom() to block on socket(s)

[ 0] IP = 10.10.10.51     PORT = 12345 # UDP
sockperf: Warmup stage (sending a few dummy packets)...
sockperf: Starting test...
sockperf: Test ended
sockperf: ========= Printing statistics for Server No: 0
sockperf: [including warmup] RunTime=20.444 sec; SentMessages=12; 
ReceivedMessages=11
sockperf: ====> avg-lat= 41.164 (std-dev=13.634)
sockperf: # dropped packets = 0; # duplicated packets = 0; # out-of-order 
packets = 0
sockperf: Summary: Latency is 41.164 usec
sockperf: Total 10 observations; each percentile contains 0.10 observations
sockperf: ---> <MAX> observation =   76.344
sockperf: ---> percentile  99.99 =   76.344
sockperf: ---> percentile  99.90 =   76.344
sockperf: ---> percentile  99.50 =   76.344
sockperf: ---> percentile  99.00 =   76.344
sockperf: ---> percentile  95.00 =   76.344
sockperf: ---> percentile  90.00 =   43.875
sockperf: ---> percentile  75.00 =   43.369
sockperf: ---> percentile  50.00 =   39.505
sockperf: ---> percentile  25.00 =   33.338
sockperf: ---> <MIN> observation =   26.772

Original comment by igor.ivanov@itseez.com on 6 Apr 2011 at 1:31

GoogleCodeExporter commented 9 years ago 
thanks, please check r44

Original comment by avne...@gmail.com on 6 Apr 2011 at 2:02

GoogleCodeExporter commented 9 years ago 
Checked with r45 (wait brings effect):

$~/prj/sockperf_r45/inst/bin/sockperf sr -i 10.10.10.51 -p 12345
sockperf:  == version #2.5.45 ==
sockperf: [SERVER] listen on:
[ 0] IP = 10.10.10.51     PORT = 12345 # UDP
sockperf: Warmup stage (sending a few dummy packets)...
sockperf: [tid 25340] using recvfrom() to block on socket(s)
sockperf: Test end (interrupted by user)
sockperf: Total 12 messages received and handled
sockperf: cleanupAfterLoop() exit

$~/prj/sockperf_r45/inst/bin/sockperf pb -i 10.10.10.51 -p 12345 
--reply-every=1 --data-file=issue16.txt
sockperf:  == version #2.5.45 ==
sockperf[CLIENT] send on:sockperf: using recvfrom() to block on socket(s)

[ 0] IP = 10.10.10.51     PORT = 12345 # UDP
sockperf: Warmup stage (sending a few dummy packets)...
sockperf: Starting test...
sockperf: Test ended
sockperf: ========= Printing statistics for Server No: 0
sockperf: [including warmup] RunTime=20.444 sec; SentMessages=12; 
ReceivedMessages=12
sockperf: ====> avg-lat= 42.483 (std-dev=17.417)
sockperf: # dropped packets = 0; # duplicated packets = 0; # out-of-order 
packets = 0
sockperf: Summary: Latency is 42.483 usec
sockperf: Test end (interrupted by signal 2)
sockperf: Total 11 observations; each percentile contains 0.11 observations
sockperf: ---> <MAX> observation =   80.096
sockperf: ---> percentile  99.99 =   80.096
sockperf: ---> percentile  99.90 =   80.096
sockperf: ---> percentile  99.50 =   80.096
sockperf: ---> percentile  99.00 =   80.096
sockperf: ---> percentile  95.00 =   69.554
sockperf: ---> percentile  90.00 =   69.554
sockperf: ---> percentile  75.00 =   42.436
sockperf: ---> percentile  50.00 =   39.026
sockperf: ---> percentile  25.00 =   28.114
sockperf: ---> <MIN> observation =   26.130

Original comment by igor.ivanov@itseez.com on 7 Apr 2011 at 2:01

GoogleCodeExporter commented 9 years ago 
thanks. this means the fix is okay :)

Original comment by avne...@gmail.com on 7 Apr 2011 at 2:17