Update clock_gettime04.c

[jiaoff]

Only considers that the configuration is 250Hz when delta = 5. When 100Hz is configured, the delta must be greater than 10ms. So modify delta = 11. Resolve:

1. TFAIL: CLOCK_REALTIME_COARSE(vDSO with old kernel spec): Difference between successive readings greater than 5 ms (2): 10
2. TFAIL: CLOCK_MONOTONIC_COARSE(vDSO with old kernel spec): Difference between successive readings greater than 5 ms (2): 10

[metan-ucw]

Can we instead just get the clock resolution and base the delta on that? We can call clock_getres() for the CLOCK_REALTIME_COARSE and if that succeeds we can use the tv_nsec rounded up to to miliseconds as the delta, right?

[jiaoff]

Can we instead just get the clock resolution and base the delta on that? We can call clock_getres() for the CLOCK_REALTIME_COARSE and if that succeeds we can use the tv_nsec rounded up to to miliseconds as the delta, right?

I don't think it needs to be very complicated. At present, the minimum frequency is 100Hz, so 11ms can meet the requirements. The detal does not require high accuracy.

[xuyang0410]

I don't think it needs to be very complicated. At present, the minimum frequency is 100Hz, so 11ms can meet the requirements. The detal does not require high accuracy.

AFAIK, clock_gettime04 hit a kernel bug on s390 because li wang found a higher value ie 8. So I think cyril's advise is meaningful. See the following url clock_gettime04: print more info to help debugging clock_gettime04: add linux-git commmit in tst_tag

[metan-ucw]

Exactly as @xuyang0410 wrote these tests are trying to assert timer precision, the delta has to be as small as possible.

[jiaoff]

Exactly as @xuyang0410 wrote these tests are trying to assert timer precision, the delta has to be as small as possible.

can you get the clock resolution？I didn't find the relevant interface.

[xuyang0410]

@jiaoff Maybe use tst_config_get api to parse the CONFIG_HZ value？

[metan-ucw]

@jiaoff What about clock_getres()?

[wangli5665]

We split the delta into the precise and coarse parts via https://github.com/linux-test-project/ltp/commit/9851deb86ef257a98d7433280161d8ca685aa669

I think this problem has been resolved, at least with no report from our testing for quite a long time.