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: Mon, 25 Feb 2008 15:44:57 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802251416340.2723@scrub.home> (raw)
In-Reply-To: <1203647951.6150.80.camel@localhost.localdomain>

Hi,

On Thu, 21 Feb 2008, john stultz wrote:

> > Again, what kind of crappy hardware do you expect? Aren't clocks supposed 
> > to get better and not worse?
> 
> Well, while I've seen much worse, I consider crappy hardware to be 100
> +ppm error. So if the hardware is perfect and the system results in
> 153ppm error, I'd consider that pretty crappy, especially if its not the
> hardware's fault.

Nevertheless this error is real, why are you trying to hide it?
This is isn't an error we can't handle, it's still perfectly within the 
limit and except that NTP reports a somewhat larger drift than you'd like 
to see, everything works fine.

> > Where do you get this idea that the 500ppm are exclusively for hardware 
> > errors? If you have such bad hardware, there is another simple solution: 
> > change HZ to 100 and the error is reduced to 15ppm.
> 
> True its not exclusively for hardware errors, and if we were talking
> about only 15ppm I wouldn't really worry about it. But when we're saying
> the system is adding 30% of the maximum error, that's just not good.

Another 30% is required for normal to crappy hardware clocks and then 
there is still enough room left.

> > I would see the point if this problem had actually any practically 
> > relevance, but this error is not a problem for pretty much all existing 
> > standard hardware. Why are you insisting on redesigning timekeeping for 
> > broken hardware?
> 
> Remember my earlier data? Where I was talking about the acpi_pm being a
> multiple of the PIT frequency? By removing CLOCK_TICK_ADJUST we got a
> 127ppm error when HZ=1000. NO_HZ drops that down to where we don't care,
> but this _does_ effect current hardware, so I'd call it relevant.

How exactly does it effect current hardware in a way that it breaks them? 
Despite this error everything still works fine, the hardware doesn't care.

> > There's nothing 'injected', that resolution error is very real and the 
> > 500ppm limit is more than enough to deal with this. _Nobody_ is hurt by 
> > this.
> 
> Sure, 500ppm is enough for most people with good hardware. But remember
> the alpha example you brought up earlier? The HZ=1200 case, with the
> CLOCK_TICK_RATE=32768? If we don't take CLOCK_TICK_ADJUST into account,
> we end up with a **11230ppm** error from the granularity issue. NTP just
> won't work on those systems.
> 
> Now granted, the three types of alpha systems that actually use that HZ
> value is probably as close to "nobody" as you're going to get, but I
> don't think we can just throw the granularity issue aside.

That's actually a good example, why it's irrelevant. First it's using a 
cycle based clock, thus the rounding error is irrelevant. Second in the 
common case they already use 1024 as HZ to reduce this error, so something 
similiar could be done for the HZ=1200 case and I suspect that it was 
already done and only CLOCK_TICK_RATE is just wrong. This mail 
http://consortiumlibrary.org/axp-list/archive/2002-11/0101.html suggest 
that this is the right thing to do.

There is _no_ reason to artificially optimize this error value, there are 
still enough other ways to improve timekeeping. The granularity error is 
there no matter what you do and as long as it's within a reasonable limit 
there is nothing that needs fixing.

bye, Roman

  reply	other threads:[~2008-02-25 14:44 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
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 [this message]
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.0802251416340.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).