linux-kernel - Re: [GIT pull] ntp updates for 2.6.31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090617172325.GA32332@localhost>
Date:	Wed, 17 Jun 2009 19:23:25 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	John Stultz <johnstul@...ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] ntp updates for 2.6.31

On Wed, Jun 17, 2009 at 08:38:22AM -0700, John Stultz wrote:
> On Tue, 2009-06-16 at 14:52 +0200, Miroslav Lichvar wrote:
> > If Linux really needs to have the fastest PLL, could it be done by
> > modifying the time constant passed in adjtimex structure instead of
> > changing SHIFT_PLL? The PLL response will be exactly the same, but it
> > will allow the applications (and admins) to detect that it is
> > different than expected.
> > 
> > Something like:
> > 
> > --- a/kernel/time/ntp.c
> > +++ b/kernel/time/ntp.c
> > @@ -425,6 +425,8 @@
> >  		time_constant = txc->constant;
> >  		if (!(time_status & STA_NANO))
> >  			time_constant += 4;
> > +		/* We want faster PLL */ 
> > +		time_constant -= 2;
> >  		time_constant = min(time_constant, (long)MAXTC);
> >  		time_constant = max(time_constant, 0l);
> >  	}
> 
> 
> It looks mathematically equivalent, although I've not had time to test
> it yet. Probably needs a bigger comment :)
> 
> The nice thing with this version is that we're able to expose that the
> behavior would be different then other systems, but the other side of
> that coin might be that when the user specifies a time_constant value,
> the interface will show a different one being used. This might cause
> some bug reports saying the interface isn't responding properly, or
> something. Although this is already the case for !STA_NANO, and so far
> few have noticed.

I have checked the NTP sources and the returned time constant is used
only for reporting, at least for NTP it shouldn't cause any problems.

Returning correct time constant will be very useful if NTP developers
decide to use lower values or have it configurable as decreasing the
constant by another two will make the PLL unstable.

Still, I'd really like to see the original behavior restored. Most of
the users complaining about slow convergence are probably just hitting
the calibration problem, which needs to be fixed by other means than
making PLL faster. Also, users of other systems seem to be happy with
their slow convergence. At least that's the impression I have from NTP
lists.

Thanks,

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/