Please find revised patch which now allows long runs of
Linux 4.x's tools/testing/selftests/timers/inconsitency_check.c
to succeed . Sorry, 3.10 was not using tk->tkr_raw.xtime_nsec
in quite the same way as the 4.15.9 kernel under which I'd done
most of the testing of this patch up to now.
The timer test program is now also updated to perform all the checks
inconsistency_check.c does, and to support a '-r <repeat>' parameter:

$ gcc -o timer timer.c
$ timer -r 100
...
Total time: 0.000001538S - Average Latency: 0.000000015S N zero
deltas: 0 N inconsistent deltas: 0
Total time: 0.000001540S - Average Latency: 0.000000015S N zero
deltas: 0 N inconsistent deltas: 0
Average of 100 average latencies of 100 samples : 0.000000017S
$

This shows the average of 100 averages of latency measurement of 100 samples
(10,000 samples of CLOCK_MONOTONIC_RAW) and double-checks that
every value is properly GREATER THAN the previous value - when
there is no difference, 'zd' is incremented , and if the difference is negative,
an inconsitency is raised and a counter is incremented - no inconsistencies
or zero deltas were found by above run.

Note, without the patch, the CLOCK_MONOTONIC_RAW average latency
found will be anywhere beween 150ns and 1000ns on the same machine with
the same program.

Thanks & Regards,
Jason Vas Dias
Software Engineer,
FAZtech / Fugro LLC,
Dublin Ireland


On 14/03/2018, Jason Vas Dias <[log in to unmask]> wrote:
> The attached kernel patch, which I have running on my
> HP EliteDesk i7-4770 4/8 core 3.3-3.9ghz workstation
> under Scientific Linux 7.4+, recently upgraded yesterday
> to the new kernel-3.10.0-693.21.1.el7.x86 and gcc-4.8.5-16.el7_4.2.x86_64,
> allows calls to :
>       struct timespec &ts;
>       clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
> to see about the same latency or less than calls to
>       clock_gettime(CLOCK_MONOTONIC, &ts);
> which, on the above machine, is now about 20ns, compared
> with 300-800ns before the patch, because the vDSO WAS
> using
>       vdso_fallback_gtod()
> , which issues a syscall, entering the kernel and doing kernel <-> user
> address space switch and copy_to_user() .
>
> Running the attached timer_latency program:
>    $ gcc -o timer_latency timer_latency.c
>
> $ ./timer_latency -?
> Usage: timer_latency
>  [ -m : use CLOCK_MONOTONIC clock
>    (not CLOCK_MONOTONIC_RAW) ;
>     -d : dump timespec contents. N_SAMPLES: 100
>  ] : Calculates average timer latency (minimum time that can be measured)
> over
>      N_SAMPLES.
> $ bash -c 'for ((i=0; i < 10; i++)); do ./timer_latency; done'
> sum: 1855
> Total time: 0.000001855S - Average Latency: 0.000000018S
> sum: 1838
> Total time: 0.000001838S - Average Latency: 0.000000018S
> sum: 1830
> Total time: 0.000001830S - Average Latency: 0.000000018S
> sum: 1828
> Total time: 0.000001828S - Average Latency: 0.000000018S
> sum: 1823
> Total time: 0.000001823S - Average Latency: 0.000000018S
> sum: 1872
> Total time: 0.000001872S - Average Latency: 0.000000018S
> sum: 1834
> Total time: 0.000001834S - Average Latency: 0.000000018S
> sum: 1848
> Total time: 0.000001848S - Average Latency: 0.000000018S
> sum: 1802
> Total time: 0.000001802S - Average Latency: 0.000000018S
> sum: 1865
> Total time: 0.000001865S - Average Latency: 0.000000018S
>
> Under unpatched  3.10.0-693.21.1.el7.x86_64 kernel, the
> same program produces widely varying latency
> results between 200 and 1000ns .
>
> I applied the patch by downloading the
> kernel-3.10.0-693.21.1.el7.x86_64.srpm ,
> editing the kernel.spec file to produce the attached kernel.spec which
> applies it, and doing "rpmbuild -ba SPECS/kernel.spec --define
> _topdir' '$PWD ..." .
>
> It produces a kernel with release 3.10.0-693.21.1.el7.jvd.x86_64
> (users will want to edit that '.jvd' in the Release: tag)  - it works
> great!
>
> The tools/testing/selftests/timers/inconsistency_test.c
> from linux 4.x+ runs fine with the '-c 4' (CLOCK_MONOTONIC_RAW)
> argument under the patched kernel, as does ntpd itself, which is
> a heavy user of CLOCK_MONOTONIC_RAW, and the ntpd
> computes much lower offsets and drift values.
>
> Just wanted to share this one with the SL community.
>
> Thanks & Best Regards,
> Jason
>