There is no perfect model. Only models that are adapted to the specific study that you want to do. SimGrid provides several advanced mechanisms that you can adapt to model the situation that you are interested in, and it is often uneasy to see where to start with. This page collects several hints and tricks on modeling situations. Even if you are looking for a very advanced, specific use case, these examples may help you to design the solution you need.
Doing Science with SimGrid¶
Many users are using SimGrid as a scientific instrument for their research. This tool was indeed invented to that extent, and we strive to streamline this kind of usage. But SimGrid is no magical tool, and it is of your responsibility that the tool actually provides sensible results. Fortunately, there is a vast literature on how to avoid Modeling & Simulations pitfalls. We review here some specific works.
In An Integrated Approach to Evaluating Simulation Credibility, the authors provide a methodology enabling the users to increase their confidence in the simulation tools they use. First of all, you must know what you actually expect to discover whether the tool actually covers your needs. Then, as they say, “a fool with a tool is still a fool”, so you need to think about your methodology before you submit your articles. Towards a Credibility Assessment of Models and Simulations gives a formal methodology to assess the credibility of your simulation results.
Seven Pitfalls in Modeling and Simulation Research is even more specific. Here are the listed pitfalls: (1) Don’t know whether it’s modeling or simulation, (2) No separation of concerns, (3) No clear scientific question, (4) Implementing everything from scratch, (5) Unsupported claims, (6) Toy duck approach, and (7) The tunnel view. As you can see, this article is a must read. It’s a pity that it’s not freely available, though.
Getting realistic results¶
The simulation models in SimGrid have been developed with care and the
object of thorough validation/invalidation campaigns. These models
come with parameters that configure their behaviors. The values of
these parameters are set based on the XML platform description
file and on parameters passed via –cfg=Item:Value
command-line arguments. A simulator may also include any
number of custom model parameters that are used to instantiate
particular simulated activities (e.g., a simulator developed with the
S4U API typically defines volumes of computation, communication, and
time to pass to methods such as
sleep_for()). Regardless of the potential
accuracy of the simulation models, if they are instantiated with
unrealistic parameter values, then the simulation will be inaccurate.
The provided default values may or may not be appropriate for
simulating a particular system.
Given the above, an integral and crucial part of simulation-driven research is simulation calibration: the process by which one picks simulation parameter values based on observed real-world executions so that simulated executions have high accuracy. We then say that a simulator is “calibrated”. Once a simulator is calibrated for a real-world system, it can be used to simulate that system accurately. But it can also be used to simulate different but structurally similar systems (e.g., different scales, different basic hardware characteristics, different application workloads) with high confidence.
Research conclusions derived from simulation results obtained with an uncalibrated simulator are questionable in terms of their relevance for real-world systems. Unfortunately, because simulation calibration is often a painstaking process, is it often not performed sufficiently thoroughly (or at all!). We strongly urge SimGrid users to perform simulation calibration. Here is an example of a research publication in which the authors have calibrated their (SimGrid) simulators: https://hal.inria.fr/hal-01523608
Modeling Churn (e.g., in P2P)¶
One of the biggest challenges in P2P settings is to cope with the
churn, meaning that resources keep appearing and disappearing. In
SimGrid, you can always change the state of each host manually, with
simgrid::s4u::Host::turn_on(). To reduce the burden when
the churn is high, you can also attach a state profile to the host
This can be done through the XML file, using the
attribute of <host>, pf_tag_cluster or
<link>. Every line (but the last) of such files describes
timed events with the form “date value”. Example:
1 0 2 1 LOOPAFTER 8 - At time t = 1, the host is turned off (a zero value means OFF) - At time t = 2, the host is turned back on (any other value than zero means ON) - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off again at time t = 11. If your profile does not contain any LOOPAFTER line, then it will be executed only once and not in a repetitive way.
Another possibility is to use the
simgrid::s4u::Link::set_state_profile() functions. These
functions take a profile, that can be a fixed profile exhaustively
listing the events, or something else if you wish.
Modeling Multicore Machines¶
Multicore machines are very complex, and there are many ways to model them. The default models of SimGrid are coarse grain and capture some elements of this reality. Here is how to declare simple multicore hosts:
<host id="mymachine" speed="8Gf" core="4"/>
It declares a 4-core host called “mymachine”, each core computing 8 GFlops per second. If you put one activity of 8 GFlops on this host, it will be computed in 1 second (by default, activities are single-threaded and cannot leverage the computing power of more than one core). If you run two such activities simultaneously, they will still be computed in one second, and so on up to 4 activities. If you start 5 activities, they will share the total computing power, and each activity will be computed in 5/4 = 1.25 seconds. This is a very simple model, but that is all what you get by default from SimGrid.
Pinning tasks to cores¶
The default model does not account for task pinning, where you manually select on which core each of the existing activity should execute. The best solution to model this is probably to model your 4-core processor as 4 distinct hosts, and assigning the activities to cores by migrating them to the declared hosts. In some sense, this takes the whole Network-On-Chip idea really seriously.
Some extra complications may arise here. If you have more activities than cores, you’ll have to schedule your activities yourself on the cores (so you’d better avoid this complexity). Since you cannot have more than one network model in a given SimGrid simulation, you will end up with a TCP connection between your cores. A possible work around is to never start any simulated communication between the cores and have the same routes from each core to the rest of the external network.
Modeling a multicore CPU as a set of SimGrid hosts may seem strange and unconvincing, but some users achieved very realistic simulations of multicore and GPU machines this way.
Modeling machine boot and shutdown periods¶
When a physical host boots up, a lot of things happen. It takes time during which the machine is not usable but dissipates energy, and programs actually die and restart during a reboot. Since there are many ways to model it, SimGrid does not do any modeling choice for you but the most obvious ones.
Any actor (or process in MSG) running on a host that is shut down
will be killed and all its activities (tasks in MSG) will be
automatically canceled. If the actor killed was marked as
simgrid::s4u::Actor::set_auto_restart() or with
MSG_process_auto_restart_set()), it will start anew with the
same parameters when the host boots back up.
By default, shutdowns and boots are instantaneous. If you want to
add an extra delay, you have to do that yourself, for example from a
controller actor that runs on another host. The best way to do so is
to declare a fictional pstate where the CPU delivers 0 flop per
second (so every activity on that host will be frozen when the host is
in this pstate). When you want to switch the host off, your controller
switches the host to that specific pstate (with
simgrid::s4u::Host::set_pstate()), waits for the amount of
time that you decided necessary for your host to shut down, and turns
the host off (with
simgrid::s4u::Host::turn_off()). To boot
up, switch the host on, go into the specific pstate, wait a while and
go to a more regular pstate.
To model the energy dissipation, you need to put the right energy consumption in your startup/shutdown specific pstate. Remember that the energy consumed is equal to the instantaneous consumption multiplied by the time in which the host keeps in that state. Do the maths, and set the right instantaneous consumption to your pstate, and you’ll get the whole boot period to consume the amount of energy that you want. You may want to have one fictional pstate for the boot period and another one for the shutdown period.
Of course, this is only one possible way to model these things. YMMV ;)