Cant run vperf under load with small pps

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Host1: LD_PRELOAD=libvma.so vperf server --tcp
2. Host2: LD_PRELOAD=libvma.so vperf under-load --tcp -i <server_ip> --pps 1

What is the expected output? What do you see instead?
vperf under-load --tcp -i 1.1.1.1 --pps=1
vperf: version #2.4.1868M
vperf: No VMA version info
vperf: Client.cpp:412:ERROR: Can`t connect socket (errno=111 Connection refused)
vperf: program exits because of an error. current value of errno=111 
(Connection refused)vperf: [tid: 11731] ------
vperf: [0] 0x56e647: vperf() [0x56e647]
vperf: [1] 0x42d7e6: vperf() [0x42d7e6]
vperf: [2] 0x4c9ae9: vperf() [0x4c9ae9]
vperf: [3] 0x4e6836: vperf() [0x4e6836]
vperf: [4] 0x583695: vperf() [0x583695]
vperf: [5] 0x583f12: vperf() [0x583f12]
vperf: [6] 0x311961ec5d: /lib64/libc.so.6(__libc_start_main+0xfd) [0x311961ec5d]
vperf: [7] 0x403229: vperf() [0x403229]

What version of the product are you using? On what operating system?
vperf 2.4.1868

Please provide any additional information below.
1.Happnes with pps up to approx 100.
2.Happens on both TCP and UDP

Original issue reported on code.google.com by igor.ivanov@itseez.com on 4 Apr 2011 at 6:25

[GoogleCodeExporter]

Meny, could you describe scenario of failure if it is differ from described 
below.

Investigation note:
vperf r1868:

1. done more than 1000 tests as
vperf sr --tcp
vperf ul -i 10.10.10.51 --tcp --pps=X
where X is value in interval (1..200)
Result:
no issue observed

2. ran client w/o server as
vperf ul -i 10.10.10.51 --tcp --pps=1
Result:
displayed output from issue description

3. ran client as UDP
vperf sr
vperf ul -i 10.10.10.51 --tcp --pps=1
Result:
displayed output from issue description

Conclusion:
Output you observed is valid case for scenarios 2 and 3.
Issue is not noticed in 1 case.
#3

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

[GoogleCodeExporter]

Meny`s note:
Scenario 2 doesn't make any sense, there is no tcp connection.
I saw it when I ran scenario 1 with small pps (approx 1-200), and also on UDP 
(scenrio 3 without (!!) the --tcp flag)

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

[GoogleCodeExporter]

Igor`s note:
Meny,
- could you send me output from server and clients sides got with d option in 
command line for the 1th scenario (I can not reproduce one);
as for UDP that it confuses me because error "Can`t connect socket" can not be 
displayed during UDP connection (it is TCP specific);

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

[GoogleCodeExporter]

Meny`s note:
D_PRELOAD=libvma.so vperf under-load -i 1.1.1.1 --pps 1
vperf: version #2.4.1871
vperf: No VMA version info
vperf[CLIENT] send on:vperf: using recvfrom() to block on socket(s)

[ 0] IP = 1.1.1.1 PORT = 11111 # UDP
vperf: Warmup stage (sending a few dummy packets)...
vperf: Starting test...
vperf: Test end (interrupted by timer)
vperf: Test ended
vperf: ========= Printing statistics for Server No: 0
vperf: No messages were received from the server. Is the server down?
vperf: Test end (interrupted by signal 2)
[root@ronaldo2 ~]# D_PRELOAD=libvma.so vperf under-load -i 1.1.1.1 --pps 10
vperf: version #2.4.1871
vperf: No VMA version info
vperf[CLIENT] send on:vperf: using recvfrom() to block on socket(s)

[ 0] IP = 1.1.1.1 PORT = 11111 # UDP
vperf: Warmup stage (sending a few dummy packets)...
vperf: Starting test...
vperf: Test end (interrupted by timer)
vperf: Test ended
vperf: ========= Printing statistics for Server No: 0
vperf: No messages were received from the server. Is the server down?
vperf: Test end (interrupted by signal 2)
[root@ronaldo2 ~]# D_PRELOAD=libvma.so vperf under-load -i 1.1.1.1 --pps 100
vperf: version #2.4.1871
vperf: No VMA version info
vperf[CLIENT] send on:vperf: using recvfrom() to block on socket(s)

[ 0] IP = 1.1.1.1 PORT = 11111 # UDP
vperf: Warmup stage (sending a few dummy packets)...
vperf: Starting test...
vperf: Test end (interrupted by timer)
vperf: Test ended
vperf: ========= Printing statistics for Server No: 0
vperf: Test end (interrupted by signal 2)
vperf: [including warmup] RunTime=1.100 sec; SentMessages=110; 
ReceivedMessages=1
vperf: No valid observations found. Try increasing test duration and/or 
--pps/--reply-every parameters
[root@ronaldo2 ~]# D_PRELOAD=libvma.so vperf under-load -i 1.1.1.1 --pps 200
vperf: version #2.4.1871
vperf: No VMA version info
vperf[CLIENT] send on:vperf: using recvfrom() to block on socket(s)

[ 0] IP = 1.1.1.1 PORT = 11111 # UDP
vperf: Warmup stage (sending a few dummy packets)...
vperf: Starting test...
vperf: Test end (interrupted by timer)
vperf: Test ended
vperf: ========= Printing statistics for Server No: 0
vperf: [including warmup] RunTime=1.100 sec; SentMessages=220; 
ReceivedMessages=2
vperf: No valid observations found. Try increasing test duration and/or 
--pps/--reply-every parameters
vperf: Test end (interrupted by signal 2)
[root@ronaldo2 ~]# D_PRELOAD=libvma.so vperf under-load -i 1.1.1.1 --pps 300
vperf: version #2.4.1871
vperf: No VMA version info
vperf[CLIENT] send on:vperf: using recvfrom() to block on socket(s)

[ 0] IP = 1.1.1.1 PORT = 11111 # UDP
vperf: Warmup stage (sending a few dummy packets)...
vperf: Starting test...
vperf: Test end (interrupted by timer)
vperf: Test ended
vperf: ========= Printing statistics for Server No: 0
vperf: Test end (interrupted by signal 2)
vperf: [including warmup] RunTime=1.100 sec; SentMessages=330; 
ReceivedMessages=3
vperf: ====> avg-lat=140.567 (std-dev=0.000)
vperf: # dropped packets = 0; # duplicated packets = 0; # out-of-order packets 
= 0
vperf: Summary: Latency is 140.567 usec
vperf: Total 1 observations; each percentile contains 0.01 observations
vperf: ---> <MAX> observation = 140.567
vperf: ---> percentile 99.99 = 140.567
vperf: ---> percentile 99.90 = 140.567
vperf: ---> percentile 99.50 = 140.567
vperf: ---> percentile 99.00 = 140.567
vperf: ---> percentile 95.00 = 140.567
vperf: ---> percentile 90.00 = 140.567
vperf: ---> percentile 75.00 = 140.567
vperf: ---> percentile 50.00 = 140.567
vperf: ---> <MIN> observation = 140.567

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

[GoogleCodeExporter]

Igor`s note:
Meny,
It is not clear how the latest output relates described issue. Output looks 
reasonable because in ul test server answers in 100 packets by default.
It does not include requested output for scenario 1 also.

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

[GoogleCodeExporter]

imported from: http://argus-bg.dnsalias.org/issues/759

Original comment by igor.ivanov@itseez.com on 4 Apr 2011 at 7:11

[GoogleCodeExporter]

The output shows that there is no traffic when using smal pps (1-200)
When I ran it with pps = 300, traffic passed.

Original comment by men...@gmail.com on 6 Apr 2011 at 8:17

[GoogleCodeExporter]

this means you reproduced the bug.  please fix it.

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

[GoogleCodeExporter]

Traffic info can be recieved from 
"vperf: [including warmup] RunTime=X sec; SentMessages=Y; ReceivedMessages=Z" 
line on client side
and
"sockperf: Total messages X received and handled" line on server side;

Meny probably means "Observation" info. In this case it can be explained by 
following as sockperf truncates little interval of time from the start of test 
and some interval at the end so as result some measurement are cut off from 
observation.

Avner, could you make clear what is a reason of doing it and if it is still 
needed.

Original comment by igor.ivanov@itseez.com on 8 Apr 2011 at 11:57

[GoogleCodeExporter]

Igor, we are ignoring first 50millisec and last 50 millisec.  That's all I 
remember.  The reason is cleaner results under load.
It should not affect you in test of few seconds.

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

[GoogleCodeExporter]

"Observation" info is not seen because the first and last measurements were 
omitted.
I have not seen the reason to do it and corrected in r47 (it looks as a bug).

There is open question related 50millisec time after test start and before test 
end.
Having it can cut off the first measurement from final result set for example 
on --reply-every=1.
Avner, I have not found any reason to keep this. 

Original comment by igor.ivanov@itseez.com on 11 Apr 2011 at 3:01

[GoogleCodeExporter]

r47 was reverted since skipping few first and few last reply-packets is part of 
tool concept.
User should follow print recommendation to increase test duration and/or 
increase pps/replies in case observations are not enough.

Original comment by igor.ivanov@itseez.com on 13 Apr 2011 at 5:32

• Changed state: Invalid