global items used:
local items used:
#define NAME:
the name of the project
#define
IFC_VERSION: interface version number
#define
INTL_VERSION: internal version number
#define
COMMENTS: comments to the version
static void
Normalize (double value, double& norm, char *unit): Assumes that
value
is given in seconds, converts it into a value that is greater or equal
to 1 and returns it in norm. The unit of the converted value is
returned in unit. The unit parameter must point to a
character array that is big enough to contain the unit string and the string
delimiter. If unit is NULL, an assert fails.
static void
PrintUsage (const char *progname): Prints a help text describing all
options.
static void
PrintVersion (): Prints the project name and version number.
global variables:
double g_delayTime:
Is needed to slow down the simulation if it sends its events too fast for
EvalSys to process them. If the value is greater than zero, then the simulation
is delayed for g_delayTime seconds per simulated second.
default: 0
double g_sleeperPeriod:
The period of the sleeper process CSleeper that
is used to delay the simulation. The value specifies how often the process
calls usleep() to delay the execution of the simulation. The simulation
executes without delay for this time, and then is delayed so that the overall
delay per simulated second is g_delayTime seconds. If the simulation
creates its events too fast for EvalSys to process, then the dummy evaluation
fails to compute the precision correctly because it processes several snapshots
from the same node before reading from the next socket. Setting the sleeper
period to a value that is less or equal to the snapshot period can remedy
this.
Note: the sleeper period is used in conjunction with the delay
time. But even if you set the delay time to zero, the sleeper process is
evoked every sleeperPeriod seconds. To avoid unnecessary overhead,
you might want to set the period to a big value if you do not need to delay
the simulation. However, the process does not induce much overhead, so
you can also leave it at the default value.
default: 1
unsigned
long g_streamOffset: The variable is used to make the behaviour of
the random streams more indeterministic. If the value is zero, then the
sequence of random numbers obtained by a particular stream after the program
has been started will always be the same. This makes simulation runs very
deterministic, and if you compare the results of two runs (i.e., two executions
of simutc) that use the same configuration, then you will not observe any
differences. But of course, when evaluating algorithms, a certain amount
of indeterminism is required. So, when the -i program option is
used, then the variable is set to a random value within [0, 1000) and this
value is used to select the starting point in the sequence of random numbers.
default: 0
global functions:
int main
(int, char**): The function first processes the options. If there
was no option that caused the program to exit, it then initializes the
C++SIM threads calling Thread::Initialize(), creates a process
of type CTester and starts it through executing
CTester::Await().
After the process is done (the simulation is finished), CTester::Exit()
is called to stop the process and the function returns.
The program recognizes several options:
You may need this parameter if the simulation sends its events so fast
that the evaluation system is flooded with events. This can cause a graphical
evaluation system to react very sluggishly to user input. So if you experience
any trouble, you can slow down the simulation with this parameter. Note
that this delay does not influence the behaviour or timing of the simulation
in any way. It just causes simulated time to pass more slowly.
This parameter is necessary to make the delay specified in the -d option
effective in all cases. Without the -p option, a dedicated process is called
every simulated second and suspends the program for delay real-time
seconds before it is allowed to continue. However, if many things happen
in this 1 second of simulated time (p.e., because the snapshot period of
the simulation is less, or because network events are turned on and messages
are generated or delivered in a burst), then you will experience periods
of low event activity interrupted by periods of very high activity, and
the evaluation will still hang during the periods of high activity. Since
this depends on the configuration data, there is no ideal solution for
the problem. So it is left up to the user to decide how often the sleeper
process should be called to delay the simulation. If you specify this parameter,
then the simulation is delayed every period simulated seconds
for period*delay real-time seconds.