LKML Archive on
help / color / mirror / Atom feed
From: Roman Zippel <>
To: John Stultz <>
Cc: lkml <>,
	Andrew Morton <>,
	Ingo Molnar <>, Steven Rostedt <>
Subject: Re: [PATCH] correct inconsistent ntp interval/tick_length usage
Date: Fri, 8 Feb 2008 18:33:20 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802081718040.3378@scrub.home> (raw)
In-Reply-To: <1201914175.6216.46.camel@jstultz-laptop>


On Fri, 1 Feb 2008, John Stultz wrote:

> > 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.

I already gave you the necessary details for how to set 
NTP_INTERVAL_LENGTH and in the previous mail I explained the basis for it. 
I really don't understand what's your problem with it. Why do you try to 
make it more complex than necessary?

> 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.

You don't create consistency by adding corrections all over the place 
until it adds up to the right sum.
The current correction is already somewhat of a hack and I'd rather get 
rid of it than to let it spread all over the place (it's really only 
needed so that people with weird HZ settings don't hit the 500ppm limit 
and we're basically cheating to the ntpd by not telling it the real 
frequency). Please keep the knowledge about this crutch at a single place 
and don't spread it.
Anyway, for NO_HZ this correction is completely irrelevant, so again 
there's no point in adding random values all over the place until you get 
the correct result.

The only other alternative would be to calculate this correction 
dynamically. For this you leave NTP_INTERVAL_LENGTH as is and when 
changing clocks you check whether "abs(((cs->xtime_interval * 
NTP_INTERVAL_FREQ) >> cs->shift) - NSEC_PER_SEC)" exceeds a certain limit 
(e.g. 200usec) and in this case you print a warning message, that the 
clock has large base drift value and is a bad ntp source and apply a 
correction value. This way the correction only hits the very few system 
which might need it and it would be the prefered solution, but it also 
requires a few more changes.

bye, Roman

  reply	other threads:[~2008-02-08 17:36 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
2008-02-08 17:33                 ` Roman Zippel [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0802081718040.3378@scrub.home \ \ \ \ \ \ \
    --subject='Re: [PATCH] correct inconsistent ntp interval/tick_length usage' \

* 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).