| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 8 Jun 2017 11:36:12 -0700
From: John Stultz <john.stultz@...aro.org>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: Richard Cochran <richardcochran@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Prarit Bhargava <prarit@...hat.com>,
Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH RFC 0/3] Improve stability of system clock
On Thu, Jun 8, 2017 at 9:17 AM, Miroslav Lichvar <mlichvar@...hat.com> wrote:
> On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote:
>> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar <mlichvar@...hat.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.
Might rename the headers for the second column set for clarity?
>
> 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.
That all sounds great!
(Though I still do really like your simulator! Being able to have
deterministic test results from known inputs is a big plus.)
thanks
-john
Powered by blists - more mailing lists