Runtime and SimTime

[OverwatchGirl]

Hello @riebl ,

I am working on something on Vanetza, which requires the use of Runtime object, and on another thing on Radio.cc which requires the use of SimeTime, as i am trying to establish the relationship between these two objects, i stumbled upon the method Runtime::convertSimTime() which i unfortunately can't use in vanetza since i can't create an object of simtime_t type, but as i tried to understand how it works, i noticed that it just converts the types meanwhile, the value is the same, ie, runtime and simtime are just different names to the same value. But as i went further in my code, i realized that simtime is much faster than runtime, ie one second in runtime equals many seconds in simtime, and this got me a little bit puzzled.

Can u please enlighten me, and if possible show me the way out of this problem.

Thank you so much for all the help u are providing us.

[riebl]

No, Runtime and SimTime do not represent the same values. The vanetza::Clock used by Runtime counts the milliseconds since 1st January 2004 ("ITS time"). SimTime starts with zero at the beginning of a simulation, i.e. you have usually an offset between these two time representations. artery::Timer is basically managing this offset for you and provides some conversion methods. Each Middleware object owns such a Timer, which can be fetched by services then.

[OverwatchGirl]

Thank you so much for your answer.

Can i use artery::Timer in both vanetza::flowControl and Radio.cc ?

[riebl]

Well, neither Vanetza nor INET depend on Artery but the other way around. Why do you need the very same time representation everywhere at all?

[OverwatchGirl]

Actually, i am implementing Token Bucket in vanetza::DCC::flowControl, where i can't usesimtime, so i am using the object Runtime, but then I'll need to evaluate the performance of my token bucket in Radio.cc where i don't have the runtime object but i have simTime (bc i implemented a token bucket for each access category, and thus I'll evaluate the performance of each access category in Radio.cc).

Now that u explained to me that runtime doesn't give time related to the simulation, but clock wall time (since January 2014), i realized that i need to use simTime in my token bucket too. Any suggestions ??

[riebl]

My suggestion: Use omnetpp::SimTime in INET code (Radio.cc), e.g. for recording event occurrences such as transmission requests. Use vanetza::Runtime in vanetza::dcc::FlowControl to periodically add new tokens to your token bucket algorithm.

I assume that you want to compare timestamps in radio and your token bucket algorithm: FlowControl has PacketDropHook and PacketTransmitHook to which you can attach custom code "from outside", e.g. from Artery. For example, you can add the following code in DccEntityBase:

mFlowControl->set_packet_drop_hook(
  [this](vanetza::access::AccessCategory ac, const vanetza::ChunkPacket*) {
    // add your code here, e.g. fetch current simulation time
    omnetpp::SimTime now = omnetpp::simTime();
  });

This hook is invoked whenever FlowControl drops a packet. Similarly, set_packet_transmit_hook allows you to register a callback function that will be invoked whenever a packet is actually transmitted.

[OverwatchGirl]

I actually want to get the data rate of the sent messages in each access category on Radio, and compare it to the theoretical rate that the token bucket is supposed to apply to the flow. and for this i need a unified time metric, which is thesimTime.

As for the hook, i don't really get what it has to do with simTime ? can u give me more explanation ?

PS : I'm so sorry, i am still a beginner with Artery and Omnetpp, so it might take me longer than average to process the information :") .

[riebl]

I thought you want to have a common time datatype and the hooks offer a way to use omnetpp::SimTime along with vanetza::dcc::FlowControl. If you just want to calculate rates in FlowControl and Radio, you only need to measure time intervals: Just subtract omnetpp::SimTime timepoints (returns a omnetpp::SimTime) or vanetza::Clock::time_point objects (returns vanetza::Clock::duration).

[OverwatchGirl]

Yes, that's what i am doing right now, but it is not logically correct, since one second in simTime, isn't the same as one second in Runtime, so the rate in all cases will not give me viable results, and comparison will be impossible.

So, u think that the use of the hook, will help me achieve my goal, which is practically, to get the number (and size) of packets enqueued in one second in flow control by the use of token bucket, and on the other side, the number (and size) of packets transmitter in radio::startTransmission, in one second also.

thank you so much for bearing with me.

[riebl]

One second is always one second irrespective of the data types: Time advances at the same speed in vanetza::Runtime as it does in OMNeT++.

[OverwatchGirl]

Ah, okey, i thought that simTime time was faster than vanetza::Runtime time, if this is the case (both times give equal metrics), then i guess that i am fine, i can work with vanetza::Runtime on flow control and simTime on Radio.cc.

thank you very much for all the explanation, you really helped me a lot.