LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: John Stultz <johnstul@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] correct inconsistent ntp interval/tick_length usage
Date: Fri, 01 Feb 2008 17:02:55 -0800	[thread overview]
Message-ID: <1201914175.6216.46.camel@jstultz-laptop> (raw)
In-Reply-To: <Pine.LNX.4.64.0801310404480.17507@scrub.home>


On Thu, 2008-01-31 at 06:02 +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 30 Jan 2008, john stultz wrote:
> 
> > My concern is we state the accumulation interval is X ns long. Then
> > current_tick_length() is to return (X + ntp_adjustment), so each
> > accumulation interval we can keep track of the error and adjust our
> > interval length.
> > 
> > So if ntp_update_frequency() sets tick_length_base to be:
> > 
> > 	u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
> > 			<< TICK_LENGTH_SHIFT;
> > 	second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
> > 	second_length += (s64)time_freq
> > 				<< (TICK_LENGTH_SHIFT - SHIFT_NSEC);
> > 
> > 	tick_length_base = second_length;
> > 	do_div(tick_length_base, NTP_INTERVAL_FREQ);
> > 
> > 
> > The above is basically (X + part of ntp_adjustment)
> 
> CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't 
> based on HZ, there is no point in using it!

Hey Roman,

Again, I'm sorry I don't seem to be following your objections. If you
want to suggest a different patch to fix the issue, it might help.

The big issue for me, is that we have to initialize the clocksource
cycle interval so it matches the base tick_length that NTP uses.

To be clear, the issue I'm trying to address is only this:
Assuming there is no NTP adjustment yet to be made, if we initialize the
clocksource interval to X, then compare it with Y when we accumulate, we
introduce error if X and Y are not the same.

It really doesn't matter how long the length is, if we're including
CLOCK_TICK_ADJUST, or if it really matches the actual HZ tick length or
not. The issue is that we have to be consistent. If we're not, then we
introduce error that ntpd has to additionally correct for.

Now, once we're consistent, then CLOCK_TICK_ADJUST can be zero or not
and it won't really matter, other then making sure we accumulate at
exact tick length units. You can set it either way with my patch and
things will still work out to be correct.

My apologies for being so thick headed if I'm just missing something. I
do appreciate the feedback.
-john


  reply	other threads:[~2008-02-02  1:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24  2:38 john stultz
2008-01-24  9:14 ` Valdis.Kletnieks
2008-01-25 14:07 ` Roman Zippel
2008-01-29  2:28   ` john stultz
2008-01-29  4:02     ` Roman Zippel
2008-01-30  2:14       ` john stultz
2008-01-31  1:55         ` Roman Zippel
2008-01-31  2:16           ` john stultz
2008-01-31  5:02             ` Roman Zippel
2008-02-02  1:02               ` John Stultz [this message]
2008-02-08 17:33                 ` Roman Zippel
2008-02-09  2:17                   ` john stultz
2008-02-09  4:47                     ` Roman Zippel
2008-02-09  5:04                       ` Andrew Morton
2008-02-09 14:13                         ` Roman Zippel
2008-02-10 18:45                     ` Roman Zippel
2008-02-12  0:09                       ` john stultz
2008-02-12 14:36                         ` Roman Zippel
2008-02-14  4:36                           ` john stultz
2008-02-16  4:24                             ` Roman Zippel
2008-02-19  1:02                               ` john stultz
2008-02-19  4:04                                 ` Roman Zippel
2008-02-20  1:50                                   ` john stultz
2008-02-20 17:08                                     ` Roman Zippel
2008-02-22  2:39                                       ` john stultz
2008-02-25 14:44                                         ` Roman Zippel
2008-02-29  4:49                                         ` [PATCH] Remove obsolete CLOCK_TICK_ADJUST Roman Zippel
2008-02-29  6:25                                           ` Ray Lee
2008-02-29 13:31                                             ` Roman Zippel
2008-02-29 22:08                                           ` Andrew Morton
2008-02-29 22:27                                             ` Roman Zippel
2008-02-29 22:38                                               ` Andrew Morton
2008-02-29 23:11                                               ` john stultz
2008-02-29 23:11                                           ` john stultz
2008-03-02  4:03                                             ` Roman Zippel
2008-02-29 18:54                                         ` [PATCH] correct inconsistent ntp interval/tick_length usage Jörg-Volker Peetz

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=1201914175.6216.46.camel@jstultz-laptop \
    --to=johnstul@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=zippel@linux-m68k.org \
    --subject='Re: [PATCH] correct inconsistent ntp interval/tick_length usage' \
    /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).