linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: "Brown, Len" <len.brown@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>,
	"Hunter, Adrian" <adrian.hunter@intel.com>
Subject: Re: Skylake (XPS 13 9350) TSC is way off
Date: Wed, 2 Dec 2015 15:38:37 -0800	[thread overview]
Message-ID: <CALAqxLVKV8G6=xBqC_D1QSXNpOC2NuKNb6gL9W3se1u=nTOhKg@mail.gmail.com> (raw)
In-Reply-To: <CALCETrU8StE-1Q7D9_06cUyn+XHBb8etR8EsYa=y_X9x3vK_Rw@mail.gmail.com>

On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
> In case it's at all useful, adjtimex -p says:
>
>          mode: 0
>        offset: 0
>     frequency: 135641
>      maxerror: 37498
>      esterror: 1532
>        status: 8192
> time_constant: 2
>     precision: 1
>     tolerance: 32768000
>          tick: 10000
>      raw time:  1449098317s 671243180us = 1449098317.671243180
>
> this suggests a rather small correction, so I really have no idea what
> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>
> John, you wrote this code.  What does the error message mean?

Basally the internal correction adjustments are getting pulled further
then it is supposed to (its concerning since in some cases we push the
clocksource mult value to be quite large, and so making a large
adjustment could possibly cause an overflow).

Awhile back I had intended to cap the max adjustment, but out of
caution I put in a warning instead to see how often this might occur.

I've seen it reported sometimes while folks were running trinity or
under a VM (suggesting that due to system delays timekeeping
management may have been delayed and the internal time error had grown
quite far, so the internal correction was being somewhat aggressive).
Though more recently (3.17 era) we've changed the internal adjustment
code to try to be more conservative to avoid over-steering w/ NOHZ, so
I'd expect fewer of these.

On a hunch, are you running chrony instead of ntpd?

thanks
-john

  reply	other threads:[~2015-12-02 23:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 20:06 Skylake (XPS 13 9350) TSC is way off Andy Lutomirski
2015-12-02 22:52 ` Brown, Len
2015-12-02 23:25   ` Andy Lutomirski
2015-12-02 23:38     ` John Stultz [this message]
2015-12-02 23:42       ` Andy Lutomirski
2015-12-02 23:55         ` John Stultz
2015-12-21  8:10           ` Jon Masters
2015-12-21 21:56             ` John Stultz
2015-12-02 23:42       ` John Stultz
2015-12-02 23:59         ` Andy Lutomirski
2015-12-03  3:25     ` Brown, Len

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='CALAqxLVKV8G6=xBqC_D1QSXNpOC2NuKNb6gL9W3se1u=nTOhKg@mail.gmail.com' \
    --to=john.stultz@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).