:S you are right...
I only try to register my users, make one or two calls between users
registered and deregistere them...
I'm going to change ratios and test it again.
Thanks
On Mon, Oct 13, 2008 at 3:08 PM, Verbeiren, David [EMAIL PROTECTED]
wrote:
2008-10-13 10:44:08.255: ERROR: Scenario ratios do not sum up to 100%:
200..
2008-10-13 10:44:08.255: ERROR: Scenario ratios do not sum up to 100%:
200..
This indicates your scenario ratios are not correct. The Problem is in run
#1. You specified ims_uac for 50% and ims_dereg for 50%. However, ratios
from previous run are preserved if not specified, hence you also inherit
ims_reg for 100% from run #0. This gives a total of more than 100% which is
not valid.
So if you really want 50% dereg, 50% uac, you should force ims_reg to 0%.
However, such a mix will obviously not work since you would be leaking
users very quickly by deregistering them without ever re-registering them
afterwards. So it's probably not what you intended to do anyway.
Also, I don't think you ever said whether the calls (even if only 1 or 2)
were actually successful or not.
-David
From: Vanessa Tejada Muñoz [mailto:[EMAIL PROTECTED]
Sent: lundi 13 octobre 2008 13:54
To: Verbeiren, David
Cc: sipp-users@lists.sourceforge.net
Subject: Re: [Sipp-users] Run basic scenarios IMS bench.
Hi again,
I would like to know which is the minimun value of users to work with the
basic scenarios in IMS bench. I attach my manager.xml. I made a lot of
chages in the parameters but maybe they are wrong now... I can not make it
work... Now, I have 8 users.
My common error_log is:
2008-10-13 10:43:59.953: Created CConsole 0x81f5570.
2008-10-13 10:43:59.954: Set TSID: slot:0 TS1 (1).
2008-10-13 10:43:59.954: accept return 20 [IP4: 192.168.34.36:53264].
2008-10-13 10:43:59.954: ~ASSIGNID=0x - 0x1.
2008-10-13 10:43:59.954: ~ASSIGNID=0x1 - 0x.
2008-10-13 10:43:59.954: Set TSID: slot:1 TS1 (0).
2008-10-13 10:44:08.255: ERROR: Scenario ratios do not sum up to 100%:
200..
2008-10-13 10:44:08.255: ERROR: Scenario ratios do not sum up to 100%:
200..
2008-10-13 10:44:09.248: User pool id[2] is empty - Quitting!.
2008-10-13 10:44:09.248: Quitting!.
2008-10-13 10:44:19.805: sipp.cpp: EXIT_TEST_RES_UNKNOWN quitting=1.
2008-10-13 10:44:19.805: final cleanup.
Thanks in advace
On Thu, Oct 9, 2008 at 2:29 PM, Verbeiren, David
[EMAIL PROTECTED] wrote:
Well... AFAIK the vanilla SIPp only supports one scenario at a time per
SIPp process instance. Hence you have 2 options:
- First run a registration scenario, then a calling or messaging
one. It won't take care of avoiding that the same user participates in
multiple calls or any such kind of coordination though. Also you would run
into problem in case you need data from the execution of the reg scenario to
be used in the subsequent ones. (like storing the Service-Route header as is
done in IMS Bench SIPp - but if you know you always get the same value from
your IMS core, there isn't much point in storing it in a dynamic
variable...)
- Create a giant scenario that combines all the scenarios you need
and uses branching to sequence them. I know folks designing the SPEC SIP
benchmark are using this technique.
IMS Bench SIPp is better at emulating actual users but you probably can get
around limitations of the vanilla SIPp.
I your intention is to run benchmarks and not just simple test, sticking to
IMS Bench SIPp is a good thing. But if you just want to test some scenarios,
vanilla SIPp seems to simplest way to me.
-David
From: Vanessa Tejada Muñoz [mailto:[EMAIL PROTECTED]
Sent: jeudi 9 octobre 2008 13:55
To: Verbeiren, David
Subject: Re: [Sipp-users] Run basic scenarios IMS bench.
Perfect,
I think the same... Then you think that I can make the same test with SIPp
(not IMS Bench) for this amount of users, and then, If I have more, trying
it with IMS Bench.
The labels in xml of sipp are different from ims_bench but I can do the
same actions more or less, like for example use variables for all scenarios,
and these king of things, Is it?
Thanks for all David.
On Thu, Oct 9, 2008 at 1:19 PM, Verbeiren, David
[EMAIL PROTECTED] wrote:
The reason is that the check for empty pool is done at time of selecting a
user and actually checks for the pool to be empty after picking the user.
With 2 users, and trying to register both, you will inevitably empty the
pool and this is why you get the failure (look in user.cpp:pick_user()
function).
To get over this error, you'd need to define at least 3 users...
This is all due to the fact that the normal operation uses statistical
selection of scenario, user, instantaneous rate and hence must be
dimensioned, in terms of users, well over the expected
