Thank you all.
With Martin's help the issue is now gone.
Carlo
M.H.VanLeeuwen wrote:
> 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<[email protected]> 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
>>> <[email protected]> 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
>>>>> <[email protected]> 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
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>> <[email protected]> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> 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: [email protected]
>>>>>>>>> To: [email protected]
>>>>>>>>> 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
>>>>>>>>> [email protected]
>>>>>>>>> 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
>>>>>>>> [email protected]
>>>>>>>> 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
>> [email protected]
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
