linux-kernel - Re: [PATCH] correct inconsistent ntp interval/tick

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: <5557.1201166073@turing-police.cc.vt.edu>
Date:	Thu, 24 Jan 2008 04:14:33 -0500
From:	Valdis.Kletnieks@...edu
To:	john stultz <johnstul@...ibm.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Roman Zippel <zippel@...ux-m68k.org>
Subject: Re: [PATCH] correct inconsistent ntp interval/tick_length usage

On Wed, 23 Jan 2008 18:38:53 PST, john stultz said:
> I recently noticed on one of my boxes that when synched with an NTP
> server, the drift value reported for the system was ~283ppm. While in
> some cases, clock hardware can be that bad, it struck me as unusual as
> the system was using the acpi_pm clocksource, which is one of the more
> trustworthy and accurate clocksources on x86 hardware.
> 
> I brought up another system and let it sync to the same NTP server, and
> I noticed a similar 280some ppm drift.

So I got curious, and dropped the patch onto my workstation - 24-rc8-mm1 x86_64
and it applied just fine with an offset reported.

Before the patch, the drift was reported as 140.67 or so.
After, it's sitting at -0.681.

Am running with hpet clocksource rather than acpi_pm, which probably explains
the 140 I see rather than the 280 John saw....

Content of type "application/pgp-signature" skipped