-
Notifications
You must be signed in to change notification settings - Fork 16
Scalability
The TSCH simulator is highly scalable given appropriate network architecture.
The simulator takes at least O(N) operations to simulate a single step in the TSCH timeline, where N is the number of nodes. Let's consider the simulatin of a single TSCH slot:
-
Nodes that have a idle slot in their TSCH schedule are simulated especially fast, as essentially a single counter needs to be decremented to simulate the actions of that node (ignoring any mobility and packet generation aspects).
-
Nodes that have not joined the network are also very fast to simulate, as the schedule on the node can be ignored.
-
Nodes with an active slot needs to iterate through its slotframes (schedule) to find which cell to use. This may take some time depending on the size of its schedule: the number of slotframes and the length of each slotframe. For instance, if the node has a one 101-slot slotframe and two 7-slot slotframe, 101+7+7=115 cells must be considered. However, the 101 slot slotframe is likely to have fewer active slots on the average: e.g. 1 of 101 compared to 1 of 7 in the case of 7-slot slotframe. If that is the case, the total impact of the 101-slot slotframe on the speed of finding the cell to ue is the same as the impact of the 7-slot slotframe.
Node simulation speed is usually not the bottleneck when running large simulations.
The number of links that need to be simulated is the main factor that determines simulation scalability. For instance, in a full-mesh topology, the number of links is O(N^2), where N is the number of node. In contrast, in a tree topology the number of links is only N-1 or O(N). For large networks, this translates to a great difference in the simulation speed.
The effect of links scales linearly with the number of active transmissions. For example, a network of 1000 links that has 1 transmissions per second requires roughly the same resources for link simulation as a network with 10 links that does 100 tranmissions per second.
Having mobile nodes in the sim means that not only node positions must be periodically updated, but that also all affected links
recalculated, and possibly created or deleted. As a result, the granularity of MOBILITY_UPDATE_PERIOD_SEC configuration setting has some impact on the simulation speed. The impact is not too large even if all nodes are mobile, unless it the update period is set to a very short value (e.g. 0.01 seconds).
The folder examples/large-network contains a configuration file for simulations of a large hierarchical network (1000 nodes). Due to the tree structure of the network, it can be simulated faster that real time on modern laptop and desktop PC.
NodeJS does not have support for multiple threads, hence, a single TSCH-Sim simulation cannot be sped up by running it on a multicore processor.
However, TSCH-Sim can be sped up by running it as multiple, concurrent instances. If the SIMULATION_NUM_RUNS option is specified, this is done automatically by the simulation engine. Multiple TSCH-Sim processes are started with identical configuration (except for the random seed, which is monotonically increased for each subsequent process). The results are stored in a single directory, and the statistics merged in a single JSON file at the termination of all simulations.