Waitset and Event-Reception

[JochenSatETAS]

Hello Iceoryx-Team

We were playing around with the test https://github.com/eclipse-iceoryx/iceoryx2/tree/main/iceoryx2-tunnel/end-to-end-tests/ping-pong/src a bit. Here we discovered the following issue:
We let the ponger.rs unchanged and added a loop to the end of the run_pinger function in the pinger.rs. With that we wanted to try out to repeat the ping-pong for hundreds of times in a row.
The thing now is that the pong_subscriber.receive() (line 89 in the pinger) did not always get the event on the first try. We had to put it into a loop to retry until we received the event. The ponger always sends the event first and then the notification, so we were unsure why we were not able to find the event always at the first try.
I'm happy to provide more info if necessary.

Thank you very much for your help!

[orecham]

Hi @JochenSatETAS,

I see you are using the test for a tunnel. Is the data going over a real network? I can anticipate a couple of possible reasons.

The network communication might introduce some latency between participants. Additionally, the Zenoh backend currently available in open-source has some additional latency due to the fact that Zenoh has a background thread. After the publisher hands the payload (or event) over to Zenoh, it is only transmitted once Zenoh's background thread has been scheduled by the OS and run. Same for receiving data on the other end.

One solution would be to configure Zenoh to reduce the latency of the background thread, although I must admit I have not tried it and am not sure if it is possible to do through configuration. Another alternative would be to implement a tunnel backend using a communication mechanism that does not have this issue.

This additional latency will not be there when communicating between participants within a single host using the iceoryx2 API without tunneling.

EDIT: I forgot to mention that the iox2 tunnel CLI in open source has a polling execution mode and by default the poll rate is 100ms. This can be reduced using the --poll argument or embedding the tunnel into your own application with its own execution semantics.

[JochenSatETAS]

Hi @orecham
Thank you for your reply. I think I misunderstood the test usecase by being not aware that this test uses an additional tunnel-SW-layer (with additional delay). I thought it was a pure IPC-test, and I wanted to play around with just a test that does an IPC-event-ping-pong. Does such a test/example already exist or could you recommend a good starting point for building one?

[elBoberido]

@JochenSatETAS here you go -> https://github.com/eclipse-iceoryx/iceoryx2/tree/main/benchmarks/event. It is between threads but with events the bottleneck it the OS which needs to schedule the application. If the OS puts an application into deep sleep, e.g. because it was inactive for a long time, it can take a some 100µs to bring it back to life.