Programming

Hi
I have a periodic task (with the highest priority) which I away every X nano-second.
I am using the function clock_nanosleep with REAL_TIME timer.
when I wake up, I versify that I was awake on time,
and check if the delta between the last time I get to sleep and the current time is X nano-second.
(I verify this with the function clock_gettime, and again with REAL_TIME timer).
sometimes when the thread wake up, the delta is not X nano second (it can be sometimes less or high above
X nanosecond)
I am connected to NTP.

1. why sometimes the thread wake up before or after X nano second (I see this through the delta)
2. if the reason is the NTP and REAL_TIME timer, why the thread wake up after it finish to sleep
and the delta is less than X nano second ?

Thanks

It would help if you provide some factual data like what OS you are using, how long does the task is asked to wait and how long does it actually does it.
I any case, on a POSIX compliant system, the clock_nanosleep call might last more than expected because the delay might be rounded up or the system might bee busy doing something else. It shouldn't be shorter unless your process is interrupted by something else.

In addition to what jlliagre said, NTP will occasionally cause the real_time clock to shift forwards or backwards to align with the external time source. If your system supports the monotonic clock option, you could try using CLOCK_MONOTONIC instead of CLOCK_REALTIME.

You haven't said anything about the return value you observed from clock_nanosleep(). If it returned 0, it should not have awakened early according to the clock you specified in your call. If it returned early due to a signal, it was a relative sleep, and the last argument to clock_nanosleep() wasn't a null pointer then clock_nanosleep() would have stored the amount of time remaining on the requested timeout in the timespec structure pointed to by that last argument.

Hi
Thanks for your answer.
- I'm using red-hat.
- the thread which is periodic has the highest priority among all the other threads.
- when the thread wake up, I check the last parameter (remain parameter) to see if the thread was interrupt, but it hasn't.

so what could be the reason that the delta (which I check with the clock_gettime function) is less than the amount of time is need to be ?
(if I look at clock_nanosleep it seem the delta is OK, but not if we look at the delta from clock_gettime)

"highest priority" has to be a realtime class - Red Hat MRG kernel.

Otherwise you will get some latency - what you are observing when the thread wakes up late. As Don said check return codes to see why the code wakes up early.

clock_gettime will reflect NTP updates to delta time as you observe it. Do you run

Code:

ckconfig ntpdate on

at startup. The reason I ask is: if the system is off time-wise
then ntp makes repeated small changes to correct the system clock. While your clock is off ntp will increment/decrement time in small intervals, so that the system clock may change relative to the clock ticks nanosleep is using to measure time.

Kind of like Relativity on a micro scale.

What does your drift file show? It is usually /etc/ntp/drift unless changed by the configuration. If the absolute value of number there is more than a few ms, then ntp will be working like mad to correct the time. It also will allow you to infer which direction ntp is attempting to correct time.