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
next prev parent 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 [PATCH] correct inconsistent ntp interval/tick_length usage 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 \
/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