Definition of realtime for zenoh

[dotChris90]

May i ask a stupid question related to realtime.
There exist the repo for bridging zenoh to DDS and seems zenoh is accepted as ROS2 middle ware. There also exist a lot of discussions and programming in area of Eclipse SDV which is automotive area.

I was now curious because i also saw things like QoS RELIABLE in opposite to zenohs best effort publishing and i also saw the term "REALTIME". But i did'nt see any example in doc or in example folders that could e.g. configure a publisher or subscriber in a way like "hey i have to publish a message in a way that the message arrive to subsriber in 20ms or 200ms" - so basically deadlines. I think they also exist in DDS.

So is realtime in meaning of "deadlines" a feature that will come or is out already and just undocumented or did i oversee sth? :)

[kydos]

Hello @dotChris90,

First of all there are no stupid questions, only stupid answers.

First off, I've just uploaded a deck that should help answer the questions. Take a look and let me know if this answer your questions.

-- @kydos

[kydos]

Seems to be fine now, can you please try again?

[dotChris90]

@kydos hello and thanks for the quick reply :D i saw the slides and first was little bit confused because missing deadline listener. on the other side i have to say from the slides your argumentations is reasonable plus the message structures are good enough to check on your own how much time was spend for the transport. on top of that i saw for IPC on the same HW i saw that zenoh enable shared memory which is actually awesome and fastest way you can do to communicate. the execution time then nearly should be equal to setting a variable in memory.

btw i also saw that your messenges have a optional timestamp but according to documentation just for router options - is there a way to enable timestamps also peer to peer? --> https://zenoh.io/docs/manual/abstractions/#timestamp

[gabrik]

It should be enough to enable it in the configuration:

{
  timestamping: {
    enabled: { router: true, peer: true, client: false },
    drop_future_timestamp: false,
  },
}

See: https://github.com/eclipse-zenoh/zenoh/blob/main/DEFAULT_CONFIG.json5#L125

If enabled Zenoh expects the peers to have a synchronized time, NTP is enough, otherwise if a machine drift too much message can be dropped (hence the drop_future_timestamp)

[dotChris90]

ok got it - but is there a possiblity to do this configuration on code level like

let mut config = zenoh_config::peer();
config.timestamping.set_enabled(Some(true)).unwrap();

saw it in some test and example folders but here it will not work since the config field enabled: consist of 3 fields { router: true, peer: true, client: false }

[dotChris90]

ok i found in zenoh-ext/examples/examples/z_pub_cache.rs how cool! :D

the code would be

use zenoh::config::{Config, ModeDependentValue};

#[tokio::main]
async fn main() {
    let mut config = zenoh_config::peer();
    config.timestamping
          .set_enabled(Some(ModeDependentValue::Unique(true)))
          .unwrap();
    
    let session = zenoh::open(config).res().await.unwrap();

so basically zenoh can give timestamps, priority messages, shared memory.

• Shared memory sounds for me like a extremly nice way to fullfil hard realtime deadlines if message exchange / ipc on the same device
• if message exchange / ipc between different ECUs in a wired local environment (not internet) you can set priorities so the real time critical messages find their way first and check timestamps to detect "message delays" and so reasons for not fulfil deadlines

ok thanks actually it feels more powerful and still more easy to use than DDS. =)