public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miroslav Lichvar <mlichvar@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Subject: [PATCHv2 0/2] Improve stability of system clock
Date: Fri,  5 Jan 2018 18:14:46 +0100	[thread overview]
Message-ID: <20180105171448.14533-1-mlichvar@redhat.com> (raw)

v1->v2
- rebased to current code
- improved commit messages

This patch set improves stability and accuracy of the system clock
when synchronized to precise time sources like the new PTP KVM clock or
NTP/PTP with hardware timestamping. The biggest difference is expected
on mostly idle systems running with NOHZ (i.e. having infrequent updates
of the clock).

The stability is affected by the error which accumulates in the
ntp_error register and its correction, which is performed by adjusting
the timekeeping multiplier. After removing the old vsyscalls, which
added an error due to nanosecond rounding, there are now three sources
of the error:
- alignment of frequency adjustments to ticks
- iterative correction of the multiplier
- limited resolution of the multiplier

Instead of trying to correct the error faster, which is difficult to do
without causing instability due to irregular updates of the clock, the
patches remove the first two sources of the error. With the only
remaining source the correction logic can be significantly simplified
and the frequency of the clock is much more stable and accurate.

The freq-step selftest (with PTI disabled to pass the check of the
precision of the MONOTONIC_RAW clock) shows a significant improvement:

Before:

Checking response to frequency step:
  Step           1st interval              2nd interval
             Freq    Dev     Max       Freq    Dev     Max
 40960     +0.131     22     147     +0.136      1       3      [OK]
 40960     +0.012     51     347     +0.005      1       3      [OK]
 40960     +3.832  25038  171297     -0.169      1       2      [OK]
 40960     +2.151  13165   89429     +0.113      1       3      [OK]
 40960     -0.095      1       2     -0.095      1       3      [OK]
   640     -0.154      1       6     -0.154      1       3      [OK]
   640     +0.003      1       6     +0.003      1       3      [OK]
   640     -0.131      2       9     -0.131      1       2      [OK]
   640     -0.026     19     125     -0.029      1       3      [OK]
   640     -0.175      1       3     -0.175      1       3      [OK]
    10     +0.001      3       9     +0.000      3       6      [OK]
    10     +0.002      7      41     +0.000      2       5      [OK]
    10     -0.000      2       5     +0.000      3       5      [OK]
    10     +0.001      5      23     -0.000      2       5      [OK]
    10     +0.000      2       5     -0.000      6      15      [OK]

After:

Checking response to frequency step:
  Step           1st interval              2nd interval
             Freq    Dev     Max       Freq    Dev     Max
 40960     +0.000      2       5     -0.000      2       5      [OK]
 40960     -0.000      2       5     -0.000      3       8      [OK]
 40960     -0.000      3       7     +0.000      3       6      [OK]
 40960     +0.000      3       6     -0.000      2       6      [OK]
 40960     -0.000      2       5     +0.000      3       7      [OK]
   640     +0.001      2       9     -0.000      2       5      [OK]
   640     -0.000      3       6     +0.000      2       5      [OK]
   640     -0.001      2       4     +0.000      1       3      [OK]
   640     -0.000      2       5     +0.000      2       4      [OK]
   640     +0.000      3       6     -0.000      3       6      [OK]
    10     -0.000      2       5     +0.000      2       5      [OK]
    10     -0.000      2       5     +0.000      2       5      [OK]
    10     +0.000      2       5     +0.000      2       5      [OK]
    10     +0.000      2       5     +0.000      2       5      [OK]
    10     +0.000      3      12     +0.000      4      11      [OK]


Miroslav Lichvar (2):
  timekeeping: Don't align frequency adjustments to ticks
  timekeeping: Determine multiplier directly from NTP tick length

 include/linux/timekeeper_internal.h |   2 +
 kernel/time/timekeeping.c           | 140 ++++++++++++------------------------
 2 files changed, 48 insertions(+), 94 deletions(-)

-- 
2.9.5

             reply	other threads:[~2018-01-05 17:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-05 17:14 Miroslav Lichvar [this message]
2018-01-05 17:14 ` [PATCHv2 1/2] timekeeping: Don't align frequency adjustments to ticks Miroslav Lichvar
2018-01-05 17:14 ` [PATCHv2 2/2] timekeeping: Determine multiplier directly from NTP tick length Miroslav Lichvar
2018-01-05 17:23 ` [PATCHv2 0/2] Improve stability of system clock Miroslav Lichvar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180105171448.14533-1-mlichvar@redhat.com \
    --to=mlichvar@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox