Marc,
I have checked-in your "chance" feature (SVN 182 -
http://sipp.sourceforge.net/snapshots/sipp.2007-03-27.tar.gz)
Documentation:
http://sipp.sourceforge.net/doc/reference.html#Randomness+in+conditional+branching
Thanks a lot Marc for this great addition.
Olivier.
On 1/7/07, Peter Higginson <[EMAIL PROTECTED]> wrote:
Hi Marc,
(I've been away so you may have sorted this out by now.) My understanding
is
that next() is called to step on to the next state whereas run() is called
to do the current state. So run() is called by next and every 1-200ms or
so
to check on retransmissions and timeouts (including pause).
Peter
Peter Higginson
Newport Networks Ltd,
Direct line 01494 470694
http://www.newport-networks.com/
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 28 December 2006 15:23
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [email protected]
Subject: RE: [Sipp-users] statistical (conditional) branching
Peter,
thanks for this explanation. I won't say I now understand all, but this
piece of code is clearer now, the total picture with next() and run()
still being somewhat obscure.
For the practical point of my "chance" code:
In fact it might not be used much in these conditions (probably only for
simulating erroneous behaviour), but the chance toss should also be in
this part of code.
Now it's not possible to add the "chance" code here as those tests to
see whether a branch is needed/done are done a second time in next(),
while a "chance toss" you can only do once (in next()). I'll try to
figure it out to do all these tests only once, it will also optimise the
code.
Jacques,
can I still do this on my 08-11-2006 code or for which version should I
make the diffs?
Best regards,
MarcVD
-----Original Message-----
From: Peter Higginson [mailto:[EMAIL PROTECTED]
Sent: 23 December 2006 11:29
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [email protected]
Subject: RE: [Sipp-users] statistical (conditional) branching
Marc,
In part answer to your point 2; at line 2950 originally we had just
found a matching receive message. With various options this section has
got a bit disconnected - it used to follow the section at lines
2753-2780. How about this for a new comment:
/* We have matched a receive in search_index and now have to decide if
* it is mandatory. It mandatory if either 1) it is not optional or 2)
* it is optional but next is set without a test or 3) it is optional,
* both next and test are set and the variable selected by test has a
* value. If mandatory we keep its cookie for future retransmissions
and
* its body for use by [last...]
*/
Instead of:
/* If this was a mandatory message, and keeps its cookie for
* future retransmissions, and its body for fields inclusion
* in our messages. Similarly if there is an explicit next label set
*/
This code implements the conditions 1), 2) and 3):
if (!(scenario[search_index] -> optional) ||
scenario[search_index]->next &&
((test == -1) ||
(test < SCEN_VARIABLE_SIZE && M_callVariableTable[test] != NULL
&&
M_callVariableTable[test]->isSet()))
) {
And this deals with the message as a mandatory receive:
msg_index = search_index;
/* Store last recv msg information */
last_recv_index = search_index;
last_recv_hash = cookie;
last_recv_msg = (char *) realloc(last_recv_msg, strlen(msg) + 1);
strcpy(last_recv_msg, msg);
return next();
I cannot help you with this next bit; I don't have it in my local
version.
The else is not needed and the warning seems to trap test set without
next being set (which is probably reasonable). The rest is to do with
timer wheels and I have not put that in my local version yet - it looks
as if receiving an optional packet delays the timeout.
} else {
int timeout = call_wake(this);
int candidate;
if (test < SCEN_VARIABLE_SIZE && M_callVariableTable[test] != NULL
&&
M_callVariableTable[test]->isSet()) {
WARNING_P1("Last message generates an error and will not be used
for next sends (for last_ varaiables)\n",msg);
}
/* We are just waiting for a message to be received, if any of the
* potential messages have a timeout we set it as our timeout. We
* start from the next message and go until any non-receives. */
for(search_index++; search_index < scenario_len; search_index++) {
if(scenario[search_index] -> M_type != MSG_TYPE_RECV) {
break;
}
candidate = scenario[search_index] -> retrans_delay;
if (candidate == 0) {
if (defl_recv_timeout == 0) {
continue;
}
candidate = defl_recv_timeout;
}
if (!timeout || (clock_tick + candidate < timeout)) {
timeout = clock_tick + candidate;
}
}
Peter Higginson
Newport Networks Ltd,
Direct line 01494 470694
http://www.newport-networks.com/
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 22 December 2006 13:54
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Sipp-users] statistical (conditional) branching
Olivier,
I only changed to the get_double, didn't receive/find a better name for
the internal variable. You can find the diff in attach (if you put it in
the main code, I can start new things on the newest version:-).
It runs here for weeks now and probabilities seem OK.
About my previous point 4: I'm still having large questions about the
receive handling code around lines 2950-2990 in call.cpp, where I
couldn't get any clue on what exactly the goal/usage of that code part
(all the tests on optional or not, variable set or not). Anybody being
able to put some little comment or documentation on that would be great.
Best regards,
MarcVD
-----Original Message-----
From: Olivier Jacques [mailto:[EMAIL PROTECTED]
Sent: 20 December 2006 16:45
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [email protected]
Subject: Re: [Sipp-users] statistical (conditional) branching
Marc,
let us know when you have a new diff, so that I can have a look at the
new version too.
Olivier.
[EMAIL PROTECTED] wrote:
**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
---------------
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the contents in this
e-mail is strictly forbidden.
---------------
**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
---------------
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the contents in this
e-mail is strictly forbidden.
---------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
--
HP OpenCall Software
http://www.hp.com/go/opencall/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
