Rob,
This should fix the issue.
Martin
--- opentask.cpp.orig 2012-10-11 23:42:47.238760490 -0500
+++ opentask.cpp 2012-10-11 23:44:43.632150448 -0500
@@ -66,7 +66,11 @@
if (open_calls_allowed && (current_calls >= open_calls_allowed)) {
return clock_tick + 100;
} else {
- return (unsigned long) (last_rate_change_time +
((calls_since_last_rate_change + 1) / (rate/rate_period_ms)));
+ unsigned int retval = (unsigned long) (last_rate_change_time +
((calls_since_last_rate_change + 1) / (rate/rate_period_ms)));
+ if (retval) {
+ return retval;
+ }
+ return clock_tick + 100;
}
}
}
On 02/19/2014 05:34 PM, Rob Day wrote:
> I haven't been able to reproduce this, I'm afraid, using either Fedora
> 20 x86_64 or i686 on an Amazon EC2 m1.medium and building from the
> 3.4.0 release code at https://github.com/SIPp/sipp/releases/tag/3.4.0.
> I used the following command line:
>
> $ ./sipp -r 1047 -rp 1000 -p 2000 -rsa google.com:9002 -sf
> ../3rd_party_registration.xml -inf fields.inf -trace_err -trace_screen
> google.com -mp 9001 -max_recv_loops 5000 -max_sched_loops 5000
>
> I used google.com just as somewhere that could easily handle a burst
> of UDP packets - my understanding of your issue is that the packets
> never get generated, so not having a valid SIP server on the receiving
> end shouldn't be a problem.
>
> 3rd_party_registration.xml is as you provided it above - fields.inf is
> very simple just so it had an injection file to use.
>
> $ cat fields.inf
> SEQUENTIAL
> a;b
>
> If you can think of anything else that may be affecting your test,
> please let me know and I'll try and reproduce it again.
>
> In the meantime, I have two suggestions. One is that you can change
> the rate of a running SIPp instance programmatically through its UDP
> control socket - see
> http://sipp.sourceforge.net/doc/reference.html#Remote+control for
> details.
>
> The other is that there is a fix which looks potentially relevant
> (https://github.com/SIPp/sipp/commit/86a19680ca64c8ea44569d965dfc46db2c64e01b)
> but which didn't quite make it into v3.4.0. So I think taking the
> latest git code may well fix your issue.
>
> Best regards,
> Rob
>
> On 19 February 2014 08:58, Rob Day<r...@rkd.me.uk> wrote:
>> Thanks - I'll set up a Fedora 20 VM tonight and see if I can reproduce the
>> bug.
>>
>> On 17 February 2014 20:48, Carlo Carrano
>> <carlo.carr...@alcatel-lucent.com> wrote:
>>> Fedora 20.
>>>
>>> Carlo R. Carrano
>>>
>>>
>>>
>>> Rob Day wrote:
>>>
>>>> Thanks for that - what about operating system and version (e.g. Mac OS
>>>> X 10.6.8, Ubuntu 12.04.3, etc.?)
>>>>
>>>> Rob
>>>>
>>>> On 17 February 2014 20:27, Carlo Carrano
>>>> <carlo.carr...@alcatel-lucent.com> wrote:
>>>>> Rob,
>>>>> I'm using the stable version 3.4.0-RTPSTREAM.
>>>>> Here is the full command line I am using:
>>>>>
>>>>> sipp -r 1041 -rp 1000 -i<local_ipv4_address> -p<port#> -rsa
>>>>> <remote_ipv4_address:port#> -sf 3rd+party_registration.xml -inf
>>>>> <filename.csv> -trace_err -trace_screen<remote_ipv4_address> -mp
>>>>> <SMP_PORT>
>>>>> -max_recv_loops 5000 -max_sched_loops 5000
>>>>>
>>>>> I don't have the chance to test with the latest code from github right
>>>>> now.
>>>>> Once I'll be able to do that, I'll let you know the results.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> Carlo R. Carrano
>>>>> Product Development Engineer - Research And Development
>>>>> Call and Session Control Servers - Dept. NA10090741
>>>>> 5420 CTS& SCG Development, Sustaining, and Project Management Team
>>>>> Tel: +1-630-713-8911
>>>>> OnNET: 287-38911
>>>>> Room: IHN 9D-429 L
>>>>> http://ihgpweb.ih.lucent.com/~carranoc/
>>>>>
>>>>> Rob Day wrote:
>>>>>> Hi Carlo,
>>>>>>
>>>>>> Does this reproduce with the latest code from
>>>>>> https://github.com/SIPp/sipp? (You may need to install
>>>>>> autoconf-archive and run './autoreconf -ivf' if it doesn't build
>>>>>> successfully with './configure&& make'.)
>>>>>>
>>>>>> Assuming it does reproduce, can you let me know what operating system
>>>>>> and version you're on, and the full command line you're using (e.g.
>>>>>> any transport type options)?
>>>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>> On 17 February 2014 19:46, Carlo Carrano
>>>>>> <carlo.carr...@alcatel-lucent.com> wrote:
>>>>>>> Abinash,
>>>>>>> thanks for replying to my request.
>>>>>>> I believe the file descriptor size is fine. I actually can go to a rate
>>>>>>> as
>>>>>>> high as 4000 regs/sec, as long as I increase the value manually, using
>>>>>>> the *
>>>>>>> and + keys (at least that's as high as I did go).
>>>>>>> However, if I start the script with a rate that is greater than 1000
>>>>>>> (i.e.
>>>>>>> '-r 1001' or greater), the script runs without generating any
>>>>>>> registration.
>>>>>>> Same goes if I try with a call load.
>>>>>>> Thanks again,
>>>>>>>
>>>>>>> Carlo R. Carrano
>>>>>>> Product Development Engineer - Research And Development
>>>>>>> Call and Session Control Servers - Dept. NA10090741
>>>>>>> 5420 CTS& SCG Development, Sustaining, and Project Management Team
>>>>>>> Tel: +1-630-713-8911
>>>>>>> OnNET: 287-38911
>>>>>>> Room: IHN 9D-429 L
>>>>>>> http://ihgpweb.ih.lucent.com/~carranoc/
>>>>>>>
>>>>>>> Abinash Sarangi wrote:
>>>>>>>
>>>>>>> Hi Carlo,
>>>>>>>
>>>>>>> Is the build a stable one ?
>>>>>>> Check the steps for increasing the file descriptor size
>>>>>>> use -buff_size set value to 1024*n( where n = 1..n)
>>>>>>> can you on the call debug option as well
>>>>>>>
>>>>>>> please check with all these options
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Abinash
>>>>>>>
>>>>>>>
>>>>>>>> Date: Sun, 16 Feb 2014 20:08:02 -0600
>>>>>>>> From: carlo.carr...@alcatel-lucent.com
>>>>>>>> To: sipp-users@lists.sourceforge.net
>>>>>>>> Subject: [Sipp-users] Cannot start a script with more than 1000
>>>>>>>> reg/sec
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I'm running sipp v3.4.0-RTPSTREAM.
>>>>>>>> I found that I am not able to start a registration script when the
>>>>>>>> registration rate is greater than 1000 reg/sec. I'm using options -r
>>>>>>>> 1047 -rp 1000.
>>>>>>>> If the registration rate is less than or equal 1000, the script works
>>>>>>>> fine. Otherwise, it starts but does not generate any load.
>>>>>>>>
>>>>>>>> Here is a screenshot for a working case:
>>>>>>>>
>>>>>>>> ------------------------------ Scenario Screen -------- [1-9]: Change
>>>>>>>> Screen --
>>>>>>>> Call-rate(length) Port Total-time Total-calls Remote-host
>>>>>>>> 1000.0(0 ms)/1.000s 5500 6.00 s 5982 135.1.216.65:5060(UDP)
>>>>>>>>
>>>>>>>> 998 new calls during 1.001 s period 0 ms scheduler resolution
>>>>>>>> 0 calls (limit 3000) Peak was 5 calls, after 0 s
>>>>>>>> 0 Running, 5983 Paused, 473 Woken up
>>>>>>>> 0 dead call msg (discarded) 0 out-of-call msg (discarded)
>>>>>>>> 3 open sockets
>>>>>>>>
>>>>>>>> Messages Retrans Timeout Unexpected-Msg
>>>>>>>> REGISTER ----------> 5982 0 0
>>>>>>>> 200<---------- E-RTD1 5982 0 0 0
>>>>>>>> ------ [+|-|*|/]: Adjust rate ---- [q]: Soft exit ---- [p]: Pause
>>>>>>>> traffic -----
>>>>>>>>
>>>>>>>>
>>>>>>>> And here is a screenshot for a non-working case:
>>>>>>>>
>>>>>>>> ------------------------------ Scenario Screen -------- [1-9]: Change
>>>>>>>> Screen --
>>>>>>>> Call-rate(length) Port Total-time Total-calls Remote-host
>>>>>>>> 1047.0(0 ms)/1.000s 5500 2.00 s 0 135.1.216.65:5060(UDP)
>>>>>>>>
>>>>>>>> 0 new calls during 1.002 s period 1 ms scheduler resolution
>>>>>>>> 0 calls (limit 3141) Peak was 0 calls, after 0 s
>>>>>>>> 0 Running, 2 Paused, 3 Woken up
>>>>>>>> 0 dead call msg (discarded) 0 out-of-call msg (discarded)
>>>>>>>> 3 open sockets
>>>>>>>>
>>>>>>>> Messages Retrans Timeout Unexpected-Msg
>>>>>>>> REGISTER ----------> 0 0 0
>>>>>>>> 200<---------- E-RTD1 0 0 0 0
>>>>>>>> ------ [+|-|*|/]: Adjust rate ---- [q]: Soft exit ---- [p]: Pause
>>>>>>>> traffic -----
>>>>>>>>
>>>>>>>>
>>>>>>>> Note that if I start the script with less than 1000 reg/sec and then I
>>>>>>>> increase them manually, everything works just fine.
>>>>>>>> Here is a screen shot showing that:
>>>>>>>>
>>>>>>>> ------------------------------ Scenario Screen -------- [1-9]: Change
>>>>>>>> Screen --
>>>>>>>> Call-rate(length) Port Total-time Total-calls Remote-host
>>>>>>>> 1030.0(0 ms)/1.000s 5500 10.01 s 10208 135.1.216.65:5060(UDP)
>>>>>>>>
>>>>>>>> 1033 new calls during 1.002 s period 0 ms scheduler resolution
>>>>>>>> 0 calls (limit 3090) Peak was 5 calls, after 2 s
>>>>>>>> 0 Running, 10209 Paused, 481 Woken up
>>>>>>>> 0 dead call msg (discarded) 0 out-of-call msg (discarded)
>>>>>>>> 3 open sockets
>>>>>>>>
>>>>>>>> Messages Retrans Timeout Unexpected-Msg
>>>>>>>> REGISTER ----------> 10208 0 0
>>>>>>>> 200<---------- E-RTD1 10208 0 0 0
>>>>>>>> ------ [+|-|*|/]: Adjust rate ---- [q]: Soft exit ---- [p]: Pause
>>>>>>>> traffic -----
>>>>>>>>
>>>>>>>>
>>>>>>>> So, it seems that sipp is capable of handling a rate greater than
>>>>>>>> 1000,
>>>>>>>> but not if starting the script with that value.
>>>>>>>>
>>>>>>>> I need to start several scripts like this from a shell script, for lab
>>>>>>>> automation registration and call load testing. Is there a way to
>>>>>>>> overcome this limitation?
>>>>>>>>
>>>>>>>> Thanks in advance for any help you can give,
>>>>>>>>
>>>>>>>> Carlo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Android apps run on BlackBerry 10
>>>>>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>>>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>>>>>> Get your Android app in front of a whole new audience. Start now.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>>>>>> _______________________________________________
>>>>>>>> Sipp-users mailing list
>>>>>>>> Sipp-users@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Managing the Performance of Cloud-Based Applications
>>>>>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>>>>>> Read the Whitepaper.
>>>>>>>
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Sipp-users mailing list
>>>>>>> Sipp-users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>>>>>>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Sipp-users mailing list
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
