From: Thomas Gleixner <firstname.lastname@example.org> To: Miroslav Lichvar <email@example.com> Cc: John Stultz <firstname.lastname@example.org>, Christopher Hall <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, linux-rt-users <email@example.com>, firstname.lastname@example.org, Gavin Hindman <email@example.com>, firstname.lastname@example.org, Peter Zijlstra <email@example.com>, LKML <firstname.lastname@example.org> Subject: Re: TSC to Mono-raw Drift Date: Fri, 2 Nov 2018 12:27:16 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.email@example.com> (raw) In-Reply-To: <20181102102613.GL19434@localhost> Miroslav, On Fri, 2 Nov 2018, Miroslav Lichvar wrote: > 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. That sounds reasonable. > > 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. Indeed. Thanks, tglx
next prev parent reply other threads:[~2018-11-02 11:27 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 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 2018-11-02 11:27 ` Thomas Gleixner [this message] 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=alpine.DEB.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).