Improvement: Step Execution Rate in op_mode NRT

[dev-gb]

Currently, the following PDUs are required to execute a simulation cycle in Op_Mode NRT.
The large number of PDUs decreases the maximal achievable step execution rate drastically.

PDU	Sender
STC_do_Step	Master
RSP_ack	Slave
NTF_state_chaged (COMPUTING)	Slave
NTF_state_changed (COMPUTED)	Slave
STC_send_outputs	Master
RSP_ack	Slave
NTF_state_changed (SENDING_D)	Slave
DAT_input_output	Slave
NTF_state_changed (RUNNING)	Slave
DAT_input_output	Master

Some of them could be omitted to increase the execution rate and decrease the network utilization. I.e. after sending the STC_do_step, the slave changes its state to computing or sends a RSP_nack. The master does not require a RSP_ack. There should be no latency between the state transmissions and the NTF_*message

[dev-gb]

Furthermore, the NTF_state_changed (SENDING_D) could be omitted.

The master would then possibly receive the NTF_state_changed (RUNNING) as the next message.
However, as the slave automatically changes to the state RUNNING, the additional message does not lead to any new or required information.

[debuti]

We have experience on simulations running HRT@0.1s faster than simulations in NRT due to the number of messages needed for the control channel. I think this is really needed, at least the removal of unnecessary intermediate states such as COMPUTING or SENDING_D

[martinkrammer]

We have experience on simulations running HRT@0.1s faster than simulations in NRT due to the number of messages needed for the control channel. I think this is really needed, at least the removal of unnecessary intermediate states such as COMPUTING or SENDING_D

COMPUTING and SENDING_D are definitely required, especially when it comes to slave-to-slave communication where the master is otherwise not aware of the slaves' states.

[martinkrammer]

NRT mode was designed to operate reproducible/reliable in scenarios with slave-to-slave data exchange.
For master-to-slave data exchange (exclusively from slave perspective) the described points are considered valid, optimizations would be possible.
Possible solutions:

• Introduce new mode without direct slave-to-slave data exchange (master-slave data exchange exclusively)

Further effort is needed as this would represent a functional update. More explanations are needed as well.

[martinkrammer]

Discussed and polled in web meeting