Orbit > OTG > Function Specifications > Timing Control

Timing

Requirements

OTG and OTR are communication programs which need good timing functions. OTG needs to control its packet deliver phase. It introduces an "wait" operation between packet transmission. OTR does not need an "wait" operation, but still need report timestamps of packet reception.

Implementation

An UnixTime class is designed for this purpose. There are two kinds of clocks in this class:

• Absolute Time: Clock refer to an absolute starting time (like 01/01/2000).
• Relative Time: Clock refer to the start of the program(construction of the UnixTime class object)

Absolute time is used for showing the rx_timestamp and tx_timestamp. Because those two timestamps will be compared to show packet delay, they have to be of some absolute reference which beyonds its respective process.

Relative clock is used to report gen_timestamp ( packet generation time). Also, this clock could be paused and resumed. To realize this, its origin_ (orgin time) would be shifted whenever an pasue-resume operation occurred.

How to get Absolute time

When the UnixTime object is constructed, it will get system time and set the reference point to the 12am of today. Therefore, packet tx_timestamp and rx_timestamp are reporting the milliseconds passed since the 12am of the experiment day by OTG and OTR independently. As long as the nodes are NTP synced, the comparison of stamps to calculate delay would be no problem.

For experiments around 12am, this is still an incomplete solution. So —clockref parameters are added in both OTG/OTR. The nodehandler could give an integer number to this option when starting otr/otg, to calibrate the timestamp-clock reference. This integer is the # of hours passed since 01/01/1970, for example, 313171 will shift the clock reference to 3pm 09/22/2005. I suggest nodehandler add a routine to calculate this number and passed it to otg/otr along with oml-name, oml-config…

TimeStamp Report in Measurements

As mentioned before, the rx_timestamp and tx_timestamp are of absolute clock. Ideally, they should be reported as floating point numbers. However, those values are usually very big. Because MySQL database does not show large float value very well, we cast them to integers. The timestamps are of integer millisecond unit.

packet generation timestamp is reported as a float variable.