Changes between Version 5 and Version 6 of Old/Documentation/OTG/FuncSpec/TimingControl
- Timestamp:
- Oct 6, 2005, 6:06:30 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Old/Documentation/OTG/FuncSpec/TimingControl
v5 v6 14 14 * Relative Time: Clock refer to the start of the program(construction of the [source:otg/trunk/src/cpp/unixtime.h#latest UnixTime] class object) 15 15 16 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 abso ulte referrence which beyonds its respective process.16 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. 17 17 18 18 Relative clock is used to report gen_timestamp ( packet generation time). Also, this clock could be paused and resumed. 19 To realize this, its origin_ (orgin time) would be shifted whenever an pasue-resume operation occur ed.19 To realize this, its origin_ (orgin time) would be shifted whenever an pasue-resume operation occurred. 20 20 21 21 == How to get Absolute time == 22 22 23 23 When the !UnixTime object is constructed, it will get system time and set the reference point to the 12am of ''today''. 24 Ther fore, packet tx_timestamp and rx_timestamp are reporting the milliseconds passed since the 12am of the experiment day by OTG and OTR indepdently.24 Therefore, packet tx_timestamp and rx_timestamp are reporting the milliseconds passed since the 12am of the experiment day by OTG and OTR independently. 25 25 As long as the nodes are NTP synced, the comparison of stamps to calculate delay would be no problem. 26 26 27 27 For experiments around 12am, this is still an incomplete solution. 28 So --clockref parameters are added in both OTG/OTR. The nodehandler could give an integer number to this option when starting otr/otg, to calib erating28 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 29 29 the timestamp-clock reference. 30 30 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 … … 34 34 == TimeStamp Report in Measurements == 35 35 36 As mentioned before, the rx_timestamp and tx_timestamp are of ab osolute clock. Ideally, they should be report as floating point numbers. However, those valuseare 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.36 As mentioned before, the rx_timestamp and tx_timestamp are of absolute clock. Ideally, they should be report 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. 37 37 38 38 packet generation timestamp is reported as a float variable.