-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time Synchronization in SIL Kit #186
Comments
The time-synchronization in SIL Kit is described in detail in the section on time synchronization in the documentation. In general, the time-synchronization ensures that all participants 'wait for each other'. When all participants have the same simulation step duration (in virtual time), then any participant will only start it's next step when all other participants have acknowledged the completion of the previous step. Using the |
Hi , Agreed on the usage of ILifecycleService part and understand that ITimeSyncService is to be configured for Time Sync. I am actually utilizing the Demo-PubSub code present in the repo. The only tweak that I did was after every publish I have added a delay for 10-secs. I did this because I initally observed that the Participant A is initially running two steps and then pausing for Participant B to catch up to 1 step. (wanted to validate this when the frames are coming at a slower rate) You can have a look at the code where I have added the change: The participants are indeed waiting for each other but not how it is anticapted. If Participant A has completed the first step it should wait till Participant B receives the data. Once participant B has received the data ; only then both of these participants move onto the next step. But in this case it does not happen like that. Participant A sends the data for the first step and then also moves to the next step and then sends the data for the next step. My initial query was, is it expected that the Sender will always move one step ahead of the receiver ? |
The behavior is as expected. The time-synchronization mechanism essentially acts as a barrier placed after the completion of a simulation step 1, which blocks the next simulation step from starting until all other participants have acknowledged that their simulation steps have ended. Keep in mind that messages from participant A to participant B can not overtake each other. This includes published messages, as well as the 'simulation-step-completed' notifications sent from A to B after A completes its simulation step. If a participant completes a simulation step, and notices that it was 'the last' to complete the step, it will, immediately after sending any messages produced during the callback 2 and sending the sim-step-completion notification, start the next simulation step. Due to the latency of message transmission, the other participants will then also start their next steps, usually slightly later that the last participant. In your example, the publisher is always the last participant to complete the simulation step - since the subscriber immediately returns from it's simulation step callback. Therefore it is also always the first to start the next step - since the subscriber is waiting for the notification from the publisher. Footnotes
|
I have two participants co-simulating in Coordinated Mode (using the PUB/SUB communication behavior)
Once both of the participants are connected and in ReadyToRun state I observe the following:
Participant A (Publisher)
-- Sends frames for the first step
-- Sends frames for the second step
-- Pause (because Participant B - Subscriber is at a very lower time point)
Participant B (Subscriber)
-- Receives frames for the first step
-- Pauses until Participant A sends frames for the next step (in this context Participant A will now send frame for the third step)
Participant A
-- After sending the data for the third step it will wait till the subscriber receives the frames for the second step (previous step)
Is this the expected behavior of Time Synchronization in SIL Kit ?
The participant A is a step ahead of participant B at all times.
The text was updated successfully, but these errors were encountered: