On 14.01.19 18:35, Philippe Gerum wrote:
clock_decrease_after_periodic_timer_first_tick checks that periodic
interval timers based on CLOCK_REALTIME are not (pathologically)
affected by the epoch going backwards.
To this end, we measure the actual time observed between two ticks of
a periodic timer based on CLOCK_REALTIME with a call to
clock_settime() injecting a negative offset in between, equivalent to
five ticks.
Due to processing delays induced by clock_settime() and other latency,
we could observe a duration which exceeds a tick by a few tenths of
microseconds. Since we can't anticipate the amount of latency
involved, let's accept a longer delay of at most two ticks.
This is still correct from the standpoint of the test, which verifies
that no correlation exists between the clock offset injected by
clock_settime() and the delay until the next tick generated by the
affected clock.
Signed-off-by: Philippe Gerum <[email protected]>
---
testsuite/smokey/posix-clock/posix-clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuite/smokey/posix-clock/posix-clock.c
b/testsuite/smokey/posix-clock/posix-clock.c
index f672a9d52..3a638d41f 100644
--- a/testsuite/smokey/posix-clock/posix-clock.c
+++ b/testsuite/smokey/posix-clock/posix-clock.c
@@ -417,7 +417,7 @@ static int
clock_decrease_after_periodic_timer_first_tick(void)
diff = now.tv_sec * 1000000000ULL + now.tv_nsec -
(timer.it_value.tv_sec * 1000000000ULL +
timer.it_value.tv_nsec);
- if (!smokey_assert(diff < 1000000000))
+ if (!smokey_assert(diff < 2000000000))
return -EINVAL;
ret = smokey_check_errno(read(t, &ticks, sizeof(ticks)));
OK, this apparently addresses the issue Henning once brought up.
You sent the patch again outside of the queue but both look identical. Will take
this one.
Finally: All 5 a also stable material as it looks like, right?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
