LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roman Zippel <zippel@linux-m68k.org>
To: john stultz <johnstul@us.ibm.com>
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: Tue, 19 Feb 2008 05:04:03 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802190219360.2723@scrub.home> (raw)
In-Reply-To: <1203382940.5984.242.camel@localhost>

Hi,

On Mon, 18 Feb 2008, john stultz wrote:

> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.

That would assume trains are always 60ft long, which is the basic error in 
your assumption.

Since we're using analogies: What you're doing is to put you winter 
clothes on your weight scale and reset the scale to zero to offset for the 
weigth of the clothes. If you stand now with your bathing clothes on the 
scale, does that mean you lost weight?
That's all you do - you change the scale and slightly screw the scale for 
everyone else trying to use it.

To keep in mind what time adjusting is supposed to do:

	freq = 1sec + time_freq

What we do instead is:

	freq + tick_adj = 1sec + time_freq

Where exactly is now the problem to integrate tick_adj into time_freq? The 
result is _exactly_ the same. The only visible difference is a slightly 
higher time_freq value and as long as it is within the 500 ppm limit there 
is simply no problem.

> And yes, if we remove CLOCK_TICK_ADJUST, that would also resolve the 
> (A!=B) issue, but it doesn't address the error from #2 below.
> [..]
> 2) We need a solution that handles granularity error well, as this is a
> moderate source of error for course clocksources such as jiffies.
> CLOCK_TICK_ADJUST does cover this fairly well in most cases. I suspect
> we could do even better, but that will take some deeper changes.

How exactly does CLOCK_TICK_ADJUST address this problem? The error due to 
insufficient resolution is still there, all it does is shifting the scale, 
so it's not immediately visible.

> My understanding of your approach (removing CLOCK_TICK_ADJUST),
> addresses issues #1 and #3, but hurts issue #2.

What exactly is hurt?

bye, Roman

  reply	other threads:[~2008-02-19  4:04 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
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 [this message]
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=Pine.LNX.4.64.0802190219360.2723@scrub.home \
    --to=zippel@linux-m68k.org \
    --cc=akpm@linux-foundation.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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).