qtime

QNX SDP8.0Building Embedded SystemsConfigurationDeveloper

Information about the system's timebase, and other time-related information

The startup library's init_qtime() function fills in the qtime data structures, which contain the following fields:
cycles_per_sec
For ClockCycles().
nsec_tod_adjust
The time-of-day adjustment for CLOCK_REALTIME and CLOCK_SOFTTIME and their timers.
nsec_inc
The number of nanoseconds per tick, an approximation of the tick_period_cc field.
boot_time
The time when the system was booted, in seconds since Jan 1 1970 00:00:00 GMT.
If you call ClockTime() to set the time of day, the kernel checks to see if this field is zero. If so, the kernel sets the field to the appropriate value. All startup programs support a -T option that prevents the setting of this field, so the kernel can set it the first time you call ClockTime(). This feature is useful if the RTC hardware isn't in UTC.
adjust
Set to zero at startup. Contains any current timebase adjustment runtime parameters (as specified by the kernel call ClockAdjust()).
timer_period
The period of one cycle of the hardware timer (to be used with timer_scale). For more information, see below.
timer_scale
The scale of timer_period so that it is represented in seconds. For example, a 1 ns period would have a timer_period of 1 and a timer_scale of -9. For more information, see below.
intr
Contains the clock interrupt vector.
epoch
Currently set to 1970, but not used.
flags
Not used.
rr_interval_mul
Reserved; set to 0.
timer_load_max
For internal use.
boot_cc
The boot time, in clock cycles. This is the epoch for all calculations done on time in clock cycles.
tick_period_cc
The exact tick period used by the kernel, in clock cycles.

The kernel computes the closest tick period value that can be represented in clock cycles from the tick frequency passed to procnto-*. Depending on the frequency requested and the hardware cycles per second (CPS), it might not be possible to represent this value in nanoseconds as an integer. In this case, nsec_inc * is only an approximation of tick_period_cc.

This can happen if the kernel is configured with a weird tick frequency that is not a factor of a sensible CPS (e.g., the system configuration passing -C 347 to procnto-*), or if the CPS itself is weird (e.g., startup-x86 calibration finding the CPS to be 1.804807028 GHz).

timer_period and timer_scale

The values in the timer_period and timer_scale fields relate to the LAPIC timer frequency (in Hz), when operating in one-shot mode, as follows:
1 / timer_period x 10 to the power of timer_scale

Yes, this relationship does imply that timer_scale is a negative number. The goal when expressing the relationship is to make timer_period as large as possible in order to maximize the significant digits available during calculations. For example, on an x86 target system the values might be 4166666666UL for timer_period and -17 for timer_scale. This indicates that the timer value is specified in hundredths of femtoseconds (the -17 means ten to the power of negative seventeen); the actual value is approximately 41666667 femtoseconds (or approximately 41.67 nanoseconds).

If the clock on your system drifts, you should make sure that the startup code specifies the correct clock frequency. To override the setting in the code, use the -f option in the startup command.

Page updated: