linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
	Christopher Hall <christopher.s.hall@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-rt-users <linux-rt-users@vger.kernel.org>,
	jesus.sanchez-palencia@intel.com,
	Gavin Hindman <gavin.hindman@intel.com>,
	liam.r.girdwood@intel.com, Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: TSC to Mono-raw Drift
Date: Fri, 2 Nov 2018 11:26:13 +0100	[thread overview]
Message-ID: <20181102102613.GL19434@localhost> (raw)
In-Reply-To: <alpine.DEB.2.21.1811011813470.1642@nanos.tec.linutronix.de>

On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so that's a frequency error of up to few hundred ppb. In the
> > old days when the clock was updated 1000 times per second that would
> > be hidden in the resolution of the clock, but now with tickless
> > kernels those steps would be very noticeable.

> That only happens when the system was completely idle for a second and in
> that case it's a non issue because the clock is updated before it's
> used. So nothing will be able to observe the time jumping forward by a few
> or even a few hundreds of nanoseconds.

That's great news (to me). I think we should do the same with the
mono/real clock. A periodic 4ns step would be better than a slew
correcting tens or hundreds of nanoseconds. This would be a
significant improvement in accuracy on idle systems, in theory
identical to running with nohz=off.

Maybe I am missing some important detail, but I think we can just drop
the +1 mult adjustment and step on each update by the (truncated)
amount that has accumulated in the NTP error register. With the
changes that have been made earlier this year the clock should never
be ahead, so the step would always be forward.

> For the regular case, where CPUs are
> busy and the update happens 100/250/1000 times per second the jump forward
> will not be noticable at all.

I think a 4ns jump at 100 Hz might be noticeable with a good reference
clock and large number of measurements, but so would be the current +1
mult adjustment.

-- 
Miroslav Lichvar

  reply	other threads:[~2018-11-02 10:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181015160945.5993-1-christopher.s.hall@intel.com>
2018-10-19 15:25 ` Thomas Gleixner
2018-10-19 18:34   ` John Stultz
2018-10-19 18:39     ` John Stultz
2018-10-19 18:37   ` Thomas Gleixner
2018-10-19 18:48     ` John Stultz
2018-10-19 18:57       ` Thomas Gleixner
2018-10-19 19:21         ` John Stultz
2018-10-19 20:50           ` Thomas Gleixner
2018-10-19 22:36             ` John Stultz
2018-10-23 18:31               ` John Stultz
2018-10-24 14:51                 ` Miroslav Lichvar
2018-10-24 17:32                   ` Christopher Hall
2018-10-25 11:49                     ` Miroslav Lichvar
2018-11-01 17:41                   ` Thomas Gleixner
2018-11-02 10:26                     ` Miroslav Lichvar [this message]
2018-11-02 11:27                       ` Thomas Gleixner
2018-11-01 17:44                 ` Thomas Gleixner
2018-11-01 17:56                   ` John Stultz
2018-11-01 18:03                     ` Thomas Gleixner
2018-11-02 11:20                       ` Miroslav Lichvar
2018-11-02 11:25                         ` Thomas Gleixner
2018-11-02 12:31                           ` 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=20181102102613.GL19434@localhost \
    --to=mlichvar@redhat.com \
    --cc=christopher.s.hall@intel.com \
    --cc=gavin.hindman@intel.com \
    --cc=hpa@zytor.com \
    --cc=jesus.sanchez-palencia@intel.com \
    --cc=john.stultz@linaro.org \
    --cc=liam.r.girdwood@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --subject='Re: TSC to Mono-raw Drift' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).