linux-kernel - Re: [RFC][PATCH] Adjust SHIFT_PLL to improve NTP convergence.

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]

Date:	Wed, 06 May 2009 08:44:00 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	ulrich.windl@...uni-regensburg.de, williams@...hat.com,
	zippel@...ux-m68k.org
Subject: Re: [RFC][PATCH] Adjust SHIFT_PLL to improve NTP convergence.

On Wed, 2009-05-06 at 10:46 -0400, George Spelvin wrote:
> > As always, feedback or testing (especially on non-x86 arches) would be
> > greatly appreciated.
> 
> Applying it to a couple of PPS-synchronized machines (where I had already
> dropped the poll interval into the basement for better convergence, have
> to try reverting that) seems to be working.


Thanks for the testing!

> One thing I just noticed, although I'm sure it has happened in the past,
> is that there's a frequency jump each boot due to TSC recalibration.
> 
> 		Machine 1	Machine 2
> Old CPU MHz	2500.170	2500.138
> Old NTP ppm	-24.63 +/-0.01	-30.27 +/-0.02
> 
> New CPU MHz	2500.176	2500.193
> New NTP ppm	-22.26 +/-0.01	-8.20 +/-0.015 
> 
> "True" CPU MHz	2500.2316	2500.2136
> 
> I should look and see if there's an easy way to tighten that tolerance.
> The current algorithm is fine for jiffies purposes, but a few seconds'
> worth of background calibration would produce a more stable estimate.

Yea. The TSC calibration issue has been around for awhile. Although the
code has been tweaked recently, I'm not seeing that much improved
consistency from reboot to reboot.

Its a hard trade off for folks who need very quick boot time, vs folks
that want very stable and accurate clocks across reboots.

I'll be looking into the calibration code to see how much is needed to
bring the error rate down.

thanks
-john


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