All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Miroslav Lichvar <mlichvar@redhat.com>
Subject: Re: [GIT pull] ntp updates for 2.6.31
Date: Tue, 16 Jun 2009 11:06:47 +0200	[thread overview]
Message-ID: <20090616090647.GD13771@elte.hu> (raw)
In-Reply-To: <1f1b08da0906151641u4cd964e6vf1a61afe50cc1d90@mail.gmail.com>


* john stultz <johnstul@us.ibm.com> wrote:

> Linus,
>     You probably didn't see this before merging.  Could you yank the
> above two patches?  Miroslav (RH package maintainer for ntpd), has
> voiced concerns that the SHIFT_PLL patch breaks the NTP design and is
> worried it may negatively effect NTP networks of systems running with
> different SHIFT_PLL values.
> 
> While the patch does greatly improve NTP convergence times, and so 
> far no negative results have been seen in tests, its out of an 
> abundance of caution and a desire to keep the adjtimex behavior 
> stable that I requested Thomas and Ingo to hold off on merging 
> this patch, while I work with Miroslav to see if we cannot get the 
> same benefit by adjusting the userspace NTPd.

As i explained it in previous threads i disagree. The only 
technically correct direction is to improve NTP stabilization and 
convergence times as much as possible. [*]

( [*] Without getting into over-compensation and without starting to
      oscillate instead of converging - that would be a bug, but 
      such a bug has not been reported so far. )

The 'concern' voiced was that: "what if other OSs converge slower in 
a cluster and now we have a faster OS in the mix". This absolutely 
ignores the other 99% of cases where people would have crappier 
convergence after the revert and for no good reason.

And even regarding that 1% example, well, duh: different OSes have 
different convergence times, fundamentally so - such as Linux had a 
very slow convergence time from about 2.6.18 up to recent kernels 
due to a bug. Now it's converging even faster ...

So i dont think that "Linux is too good" is a good basis to 
artificially make Linux's NTP code crappier. Really. We dont 'play 
nice' by being equally crappy.

Each OS should converge back to the correct time _as fast as 
physically possible_. If this is a problem and if someone wants 
crappy time and longer periods of convergence for some odd reason 
then that header file change can be edited by hand even. It's not 
like it's that hard to change, if there's genuine interest.

So i'm against any revert on this basis. If another basis comes up 
we can reconsider of course. What do you think?

	Ingo


  reply	other threads:[~2009-06-16  9:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-15 14:06 [GIT pull] ntp updates for 2.6.31 Thomas Gleixner
2009-06-15 20:16 ` john stultz
2009-06-15 23:41   ` john stultz
2009-06-16  9:06     ` Ingo Molnar [this message]
2009-06-16 11:29       ` Thomas Gleixner
2009-06-16 12:52       ` Miroslav Lichvar
2009-06-17 15:38         ` John Stultz
2009-06-17 16:51           ` Ingo Molnar
2009-06-17 17:23           ` Miroslav Lichvar
2009-06-17 17:26             ` Ingo Molnar
2009-06-17 17:55               ` John Stultz
2009-06-18 12:13               ` Miroslav Lichvar
2009-06-23  9:57                 ` Ingo Molnar
2009-06-23 13:16                   ` Miroslav Lichvar
2009-06-23 13:36                     ` Ingo Molnar
2009-06-23 14:33                       ` Miroslav Lichvar
2009-06-23 19:18                         ` Ingo Molnar
2009-06-23 19:49                           ` Miroslav Lichvar
2009-06-23 21:41                       ` john stultz
2009-06-24  9:29                         ` Alan Cox
2009-06-24 13:39                           ` Martin Schwidefsky

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=20090616090647.GD13771@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlichvar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.