You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This page describes recommended techniques to optimize the host operating system for real-time execution of DPsim.
8
8
9
-
In principle, real-time execution is supported on all platforms.
10
-
However, we recommend to use an optimized Linux installation.
9
+
DPsim supports real-time execution, where the simulation time equals the real or wall clock time, on any system.
10
+
However, without modifying system parameters the minimum time step reliably achievable will not be in the range of microseconds.
11
+
This is due to operating system noise and other processes interfering with the simulation.
12
+
With proper tuning, we have achieved real-time time steps as low as 5 us synchronized to a FPGA using VILLASnode.
13
+
Synchronizing the time step to an external source is only necessary, when very high time step accuracy, with maximum deviations in the nanoseconds, is required.
11
14
12
-
## Operating System and Kernel
13
-
14
-
For minimum latency several kernel and driver settings can be optimized.
15
-
16
-
To get started, we recommend the [Redhat Real-time Tuning Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html/Realtime_Tuning_Guide/index.html).
17
-
18
-
A [PREEMPT_RT patched Linux](https://rt.wiki.kernel.org/index.php/Main_Page) kernel is recommended.
19
-
Precompiled kernels for Fedora can be found here: http://ccrma.stanford.edu/planetccrma/software/
20
-
21
-
Use the *tuned* tool for improving general real-time performance.
22
-
Please adjust the setting `isolated_cpucores` according to your hardware and enable the `realtime` profile as follows:
As a reference, real-time simulation examples are provided in the Examples/Cxx folder of the DPsim repository.
33
-
34
-
In order to run a real-time simulation, the simulation process must be started in a special way in order to change the execution priority, scheduler and CPU affinity.
35
-
For this purpose the `chrt` and `taskset` commands are used.
36
-
In the following example, we pin the execution of the simulation to CPU cores 6-7 which have been reserved previously by the tuned real-time profile (see above).
37
-
38
-
$ taskset --all-tasks --cpu-list 6-7 \
39
-
$ chrt --fifo 99 \
40
-
$ Examples/Cxx/RT_DP_CS_R_1
41
-
42
-
More details:
16
+
## Operating System and Kernel
43
17
18
+
Using a Linux kernel with the `PREEMPT_RT` feature improves latency when issuing system calls and enables the FIFO scheduler that lets us avoid preemption during the real-time simulation.
19
+
20
+
Most distributions offer a binary package for a `PREEMPT_RT` enabled kernel. For example on Rocky Linux:
if(CMAKE_BUILD_TYPE STREQUAL "Release" OR CMAKE_BUILD_TYPE STREQUAL "RelWithDebInfo")
62
+
- add_compile_options(-flto -march=native -Ofast)
63
+
+ add_compile_options( -Ofast)
64
+
endif()
65
+
66
+
# Get version info and buildid from Git
67
+
```
68
+
69
+
## Running a Real-Time Simulation
70
+
71
+
Before running a simulation, you can run the following commands as root:
72
+
```bash
73
+
echo"evacuating cores"
74
+
tuna isolate -c 9,11,13,15
75
+
76
+
echo"disabling RT throttling"
77
+
echo -1 > /proc/sys/kernel/sched_rt_runtime_us
78
+
79
+
echo"stopping systemd services"
80
+
systemctl stop polkit
81
+
systemctl stop containerd
82
+
systemctl stop crond
83
+
systemctl stop chronyd
84
+
```
85
+
86
+
As a reference, real-time simulation examples are provided in the `dpsim/examples/cxx` and `dpsim-villas/examples/cxx` folder of the DPsim repository.
87
+
88
+
To benefit from the `PREEMPT_RT` feature and the isolated cores, the simulation has to be started using the `chrt` command to set the scheduling policy and priority, and the `taskset` command to pin the process to the isolated cores.
In the following example, we set the FIFO scheduling policy with the highest priority (99) and pin the execution of the simulation to CPU cores 9,11,13,15 which have been reserved previously (see above).
48
93
49
-
Some proposals for the selection of appropriate server hardware:
Copy file name to clipboardExpand all lines: docs/hugo/content/en/docs/Overview/interfaces.md
+31-20Lines changed: 31 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,30 +1,41 @@
1
1
---
2
2
title: "Interfaces"
3
3
linkTitle: "Interfaces"
4
-
date: 2022-12-13
4
+
date: 2025-02-13
5
5
---
6
6
7
-
Interfaces can be used to share data between a DPsim simulation and other, external services, for example an MQTT-broker. For the purpose of this guide, all services receiving and transmitting data besides the running DPsim instance are grouped in the term **environment**. Therefore, interfaces
8
-
provide a way for a DPsim simulation to exchange data with the environment.
9
-
This data is stored in the form of [Attributes]({{< ref "./Attributes/index.md" >}}) and can be **imported** or **exported** in every simulation time step. Exporting an attribute means that on every time step, the current value of that attribute is read and written out to the environment.
10
-
Importing an attribute means that on every time step, a new value is read from the environment and the attribute in the simulation is updated to match this value.
7
+
Interfaces can be used to exchange simulation signals between a DPsim simulation and other soft- or hardware, for example an MQTT-broker or an FPGA.
8
+
Simulation signals in the form of [Attributes]({{< ref "./Attributes/index.md" >}}) can be **imported** or **exported** once per simulation time step.
9
+
Interfaces are subclasses of `Interface` and implement the methods `addExport` and `addImport`, which add dependencies to the passed attribute that forward the attribute value from or to the interface.
10
+
This way, attributes that are imported are read from the interface before they are used in any DPsim component.
11
+
Attributes that are exported are written to the interface after they are set by a DPsim component.
11
12
12
-
## Configuring an Interface
13
-
On the configuration level, an interface is an instance of the `Interface` class.
14
-
Because the base `Interface` class requires an instance of an `InterfaceWorker` to construct, it is recommended to not use this base class directly,
15
-
but instead construct a subclass derived from `Interface` which internally handles the construction of the `InterfaceWorker`. Currently, there exists
16
-
only one such subclass in DPsim which is the `InterfaceVillas`.
13
+
## Interfacing with VILLASnode
17
14
18
-
### Configuring the InterfaceVillas
15
+
> This feature requires the compilation of DPsim with the `WITH_VILLAS` feature flag. For use of the VILLASnode interface in python, the `dpsimpyvillas` target has to built in addition to the normal `dpsimpy` package.
19
16
20
-
> This feature requires the compilation of DPsim with the `WITH_VILLAS` feature flag. For use of the `InterfaceVillas` in python, the `dpsimpyvillas` target has to built in addition to the normal `dpsimpy` package.
17
+
The VILLASnode interface is designed to make use of the various node types and protocols supported by the [VILLASframework](https://github.com/VILLASframework/node).
18
+
By utilizing the nodes provided by VILLASnode, it can be configured to import and export attributes using a wide range of protocols.
19
+
There are two interface implementations for VILLASnode: `InterfaceVillasQueued` and `InterfaceVillasQueueless`.
20
+
`InterfaceVillasQueued` uses a ring buffer to store signal data between DPsim and VILLASnode to allow the protocol used in VILLASnode to operate at a different rate and non-synchronized to the DPsim time step.
21
+
`InterfaceVillasQueueless` uses direct communication with a VILLASnode node type implementing a specific protocol without using a buffer, thus enabling significantly lower latency communication.
22
+
With `InterfaceVillasQueueless`, the protocol operates at the time step of DPsim, i.e., an attribute update directly triggers a `write()` call to the connected VILLASnode node type.
23
+
`InterfaceVillasQueued` should be used when using non- or soft real-time protocols or communication mediums, such as MQTT or connections via the internet.
24
+
`InterfaceVillasQueueless` should be used when communicating using reliable, low latency, real-time protocols, e.g., with FPGAs, via dedicated fibre networks, or with local real-time applications.
21
25
22
-
The `InterfaceVillas` is an interface designed to make use of the various node types and protocols supported by the [VILLASframework](https://github.com/VILLASframework/node). By utilizing the nodes provided by VILLASnode, the `InterfaceVillas` can be configured to import and export attributes from and to a wide range of external services. To create and configure an `InterfaceVillas` instance, create a new shared pointer of type `InterfaceVillas` and supply it with a configuration string in the first constructor argument. This configuration must be a valid JSON object containing the settings for the `VILLASnode` node that should be used for data import and export.
23
-
This means that the JSON contains a `type` key describing what node type to use, as well as any additional configuration options required for this node type. The valid configuration keys can be found in the [VILLASnode documentation](https://villas.fein-aachen.org/doc/node-node-types.html).
26
+
To create and configure one of the VILLASnode interface instance, create a new shared pointer of type `InterfaceVillasQueued` or `InterfaceVillasQueueless` and supply it with a configuration string in the first constructor argument.
27
+
This configuration must be a valid JSON object containing the settings for the VILLASnode node type that should be used for data import and export.
28
+
This means that the JSON contains a `type` key describing what node type to use, as well as any additional configuration options required for this node type.
29
+
The valid configuration keys can be found in the [VILLASnode documentation](https://villas.fein-aachen.org/doc/node-node-types.html).
24
30
25
-
After the `InterfaceVillas` object is created, the `exportAttribute` and `importAttribute` methods can be used to set up the data exchange between
26
-
the DPsim simulation and the configured node. For an explanation of the various parameters, see the code documentation in `InterfaceVillas.h`. The attributes given as the first parameter to these methods are attributes belonging to components in the simulation which should be read or updated by the interface.
27
-
As an example, for exporting and importing attributes via the MQTT protocol, the `InterfaceVillas` can be configured as follows:
31
+
> Note for `InterfaceVillasQueueless`:
32
+
> The queueless interface expects the first input signal in the VILLASnode configuration to be a sequence number that is incremented every time step.
33
+
> If the value of the sequence number is not incremented by one between two consecutive time steps, an overrun is detected.
34
+
> Because logging outputs can cause large delays and overruns should not occur spuriously, the interface only reports a warning when a large number of overruns occur.
35
+
36
+
After the object is created, the `exportAttribute` and `importAttribute` methods can be used to set up the data exchange between the DPsim simulation and the configured node.
37
+
The attributes given as the first parameter to these methods are attributes belonging to components in the simulation which should be read or updated by the interface.
38
+
As an example, for exporting and importing attributes via the MQTT protocol, the VILLASnode interfaces can be configured as follows:
This method will add two new [Tasks]({{< ref "./Scheduling/index.md" >}}) to the simulation. The interface's `PreStep` task is set to modify all attributes that are imported from the environment and is therefore scheduled to execute before any other simulation tasks that depend on these attributes.
92
103
The interface's `PostStep` task is set to depend on all attributes that are exported to the environment and is therefore scheduled to execute after any other simulation tasks that might modify these attributes. To prevent the scheduler from just dropping the `PostStep` task since it does not modify any attributes and is therefore not seen as relevant to the simulation, the task is set to modify the `Scheduler::external` attribute.
93
104
Note that the execution of these tasks might not necessarily coincide with the point in time at which the values are actually written out to or read from the environment.
94
-
This is because the interface internally spawns two new threads for exchanging data with the environment and then uses a **lock-free queue** for communication between these reader and writer threads, and the simulation. Because of this, time-intensive import or export operations will not block
105
+
This is because the interface internally spawns two new threads for exchanging data with the environment and then uses a **lock-free queue** for communication between these reader and writer threads, and the simulation. Because of this, time-intensive import or export operations will not block
95
106
the main simulation thread unless this is explicitly configured in the interface's `importAttribute` and `exportAttribute` methods.
96
107
97
108
## Synchronizing the Simulation with the Environment
@@ -103,4 +114,4 @@ which have `syncOnSimulationStart` set, the `Simulation::sync` will be called be
103
114
- block until all attributes with `syncOnSimulationStart` set have been read from the environment at least once
104
115
- write out all exported attributes again
105
116
106
-
Note that this setting operates independently of the `blockOnRead` flag. This means that with both flags set, the simulation will block again after the synchronization at the start of the first time step until another value is received for the attribute in question.
117
+
Note that this setting operates independently of the `blockOnRead` flag. This means that with both flags set, the simulation will block again after the synchronization at the start of the first time step until another value is received for the attribute in question.
0 commit comments