Xenomai Timer :Xenomai has two time sources: the sytem timer, which counts the number of nanoseconds since 1970, and a hardware dependent high resolution counter which counts the time since an unspecified point in time (usually the system boot time). This hardware dependent high resolution counter is called “tsc” on a PC, and gave its name to Xenomai native API calls.rt_timer_tsc returns the value of this hardware dependent high-resolution counter.
rt_timer_info returns the same thing in the tsc member of the RT_TIMER_INFO structure, and the value of the system timer at exactly the same time as when the high-resolution counter was read.

This allows to have a correspondence between the two time sources.

rt_alarm_inquire is not related to this and returns some information
about a given alarm. Now, if you allow me, a little advice for the implementation of a “timer library”: you could be tempted to create only one periodic alarm object with Xenomai, and to manage a timer list yourself. Don’t do this. Creating an alarm object for each timer library object make Xenomai aware of the existence of all your application timers, this has several

advantages:
– it gives you information about all your timers in /proc/xenomai
– it allows Xenomai to use its anticipation algorithm for all your timers
– if you are concerned about the scalability of Xenomai timers list
management, you can check the options in the “Scalability” menu of
Xenomai configuration menu (“Real-time subsystem” sub-menu of kernel
configuration menu).
more about timers

Xenomai POSIX skin supports two clocks:
CLOCK_REALTIME maps to the nucleus system clock, keeping time as the amount of time since the Epoch, with a resolution of one system clock tick.

CLOCK_MONOTONIC maps to an architecture-dependent high resolution counter, so is suitable for measuring short time intervals. However, when used for sleeping (with clock_nanosleep()), the CLOCK_MONOTONIC clock has a resolution of one system clock tick, like the CLOCK_REALTIME clock.[1]