This test is rather crude because any latencies in the exec and wait
calls are also included in the "time". Larger sleep times cause the
impact of these latencies to be less important.
The problem is caused by the update wall clock routine adding less
than 1/HZ for each jiffie. In the x86 case this was done to more
closely follow the actual time that the PIT gives with the count that
results from 1/HZ. IMHO, the result is NOT standard conforming and
another way of doing things should be found. What actually results
here is that CLOCK_MONOTONIC and CLOCK_REALTIME do not pass time at
the same rate.
The clock update value is computed by TICK_NSEC() located in
include/linux/timex.h and gives other than 1/HZ based on the LATCH and
CLOCK_TICK_RATE not yielding an exact integer value.
All this said, I don't have a good solution. The best thing would be
if we could actually generate the 1/HZ tick with 1 to 2 ppm accuracy.
If this is not possible, short of going to a new way of time keeping
(which is what the high-res-timers do) I don't see a solution. By
"good" I mean one that keeps CLOCK_MONOTONIC and CLOCK_REALTIME in
lock step (excepting clock setting which only CLOCK_REALTIME does).
Note that I am NOT excepting NTP adjustments. In other words, a good
solution would keep CLOCK_MONOTONIC as the standard clock and just
have a offset to get to CLOCK_REALTIME. This offset is what clock
setting would change.
This would, I am afraid, also introduce another problem, i.e. that the
run_timer_list() must occur very shortly after jiffies is advanced.
This requires the generation of tick interrupts to by synced to the
clock. What I am saying is that it is not enough to calculate jiffies
in a way that takes care of a higher resolution (i.e. a sub_jiffie
part) but one must also conspire to make the run_timer_list() occur
when the sub_jiffie is "small".
>
> Here is a part of the log of 'do_test':
>
> Testing behavor with clock seting...
> Retarding the clock
> Clock did not seem to move
> was: 1046969027s 703359000ns
> requested: 1046969023s 703359000ns
> now: 1046969022s 467072000ns
> diff is -1.236286998sec
> Cool clock_nanosleeptest.c,379:clock_nanosleep(clock, TIMER_ABSTIME,
> &ts, NULL)
This is BAD! The code only retards the clock by 1 sec so it appears
that nothing happened here. Oh, I know, it is saying that clock_set
failed. You must run as root to make this work. Otherwise, well I
don't know what could be happening.
>
> Testing signal behavor...
> handler1 entered: signal 31
> expected clock_nanosleeptest.c,227:clock_nanosleep(clock, 0, &ts, &rs):
> Interrupted system call
> Time remaining is 0s 989257306ns
> clock_nanosleeptest.c,245:slept too short!
> requested: 275s 207032000ns
> now: 275s 207030632ns
> diff is -0.000001368sec
This is likely caused by what I discussed above.
>
> Testing undelivered signal behavor...
> Cool clock_nanosleeptest.c,267:clock_nanosleep(clock, 0, &ts, &rs)
> clock_nanosleeptest.c,283:slept too short!
> requested: 275s 223633000ns
> now: 275s 223632698ns
> diff is -0.000000302sec
>
>
> --Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/