On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote: > >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar <mlich...@redhat.com> > >> wrote: > >> > Is there a better way to run the timekeeping code in an userspace > >> > application? I suspect it would need something like the Linux Kernel > >> > Library project.
> So a few years ago I mentioned this at a testing session at I think > Linux Plubmers' and Rusty (CC'ed) commented that he had some netfilter > (or iptables?) simulator code that never made it upstream. However, > now that kselftests are integrated with the kernel this could change. > At least that's my memory of the discussion. > > Anyway, I still think its worth trying to submit. Worse case its a > huge pain and we pull it back out? I've tried something different. I've reimplemented the simulated test as an ordinary user-space application using the CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW clocks. It's not deterministic, it doesn't give results instantly, and it's not as precise as the original test, but it can clearly show the difference that this patchset makes. Before: Clock precision: 46 ns CLOCK_MONOTONIC_RAW frequency offset: 0.00 ppm base step freq dev max freq dev max 15.24 40960 -0.04 273 1852 +0.01 2 3 228.26 40960 +6.07 33089 225914 -0.09 2 4 55.42 40960 -11.90 46413 232834 +0.01 1 3 237.65 40960 -4.75 25574 173479 +0.05 1 3 240.63 40960 -0.08 846 5758 +0.05 2 3 205.52 640 -0.11 781 5231 -0.01 2 4 246.81 640 +0.21 809 5486 +0.08 1 3 164.04 640 +0.16 282 1920 +0.11 2 3 171.32 640 -0.08 408 2756 -0.01 2 3 243.04 640 -0.03 349 2377 +0.03 2 3 179.91 10 +0.07 28 62 -0.00 2 6 45.44 10 +0.10 18 119 +0.00 6 29 204.30 10 -0.00 21 122 -0.00 4 9 76.18 10 +0.03 39 85 -0.00 3 5 158.18 10 -0.02 26 94 -0.00 4 9 After: Clock precision: 46 ns CLOCK_MONOTONIC_RAW frequency offset: -0.00 ppm base step freq dev max freq dev max 93.98 40960 +0.00 3 7 +0.00 4 8 117.95 40960 +0.00 3 9 -0.00 3 8 230.44 40960 -0.00 4 9 -0.00 2 5 240.56 40960 +0.00 3 6 -0.00 3 7 228.39 40960 +0.00 3 7 -0.00 3 9 237.85 640 -0.00 4 10 +0.00 3 8 250.74 640 +0.00 4 11 -0.00 3 7 249.06 640 +0.00 4 9 -0.00 3 9 114.98 640 -0.00 3 8 +0.00 3 8 120.59 640 +0.00 3 7 +0.00 3 7 190.66 10 -0.00 3 7 +0.00 3 7 228.83 10 +0.00 3 7 -0.00 3 6 18.91 10 +0.00 3 8 -0.00 3 8 12.39 10 +0.00 3 8 +0.00 4 8 12.01 10 +0.00 4 9 -0.00 4 9 Each line has statistics from 100 samples collected in 0.1 second interval. The frequency error in the second "freq" column with values up to 0.11 ppm shows the problem with the clock very slowly correcting a large NTP error. I can add some limits for the measured errors and submit it as new a kselftest. If the measured precision is too large (e.g. >100ns), the test can return "skip" in order to avoid false negatives. If adjtimex() had an option to return the NTP error directly, or it was possible to read the two clocks at the same time, the test could be much more sensitive and observe shorter intervals (spanning fewer clock updates). -- Miroslav Lichvar