linux-kernel - Re: Linux 2.6.29-rc6

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, 04 Mar 2009 10:57:55 -0800
From:	John Stultz <johnstul@...ibm.com>
To:	Jesper Krogh <jesper@...gh.cc>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

On Wed, 2009-03-04 at 19:36 +0100, Jesper Krogh wrote:
> Jesper Krogh wrote:
> > john stultz wrote:
> >> I guess something to test my idea above (that the drift is bad enough
> >> that NTPd isn't making slew adjustments via adjtimex offset) is to
> >> remove NTPd from the init.d startup.
> >>
> >> Then after rebooting (into 2.6.29), run the attached python script for
> >> 10 minutes or so to get an idea of the ppm drift. Then repeat with
> >> 2.6.26.
> >>
> >> To run: ./drift-test.py <ntp server>
> >>
> >> It will give some wild ppm numbers, but after a few minutes it should
> >> settle down to the "natural drift" of the system.
> > 
> > Ok. I removed ntpd from the system... heres is from "non-working 
> 
> Updated. I think I has NTPd running in the former "non-working" test. I 
> just tried to reproduce the numbers, and they look like this 
> (reproducible on 2.6.29-rc6).

Yea, the last numbers did look odd :)

> jk@...d12:~$ python drift-test.py 10.192.96.19
> 04 Mar 19:27:10         offset: -0.157696       drift: -693.0 ppm
> 04 Mar 19:28:10         offset: -0.195134       drift: -625.098360656 ppm
> 04 Mar 19:29:10         offset: -0.232579       drift: -624.595041322 ppm
> 04 Mar 19:30:10         offset: -0.270021       drift: -624.408839779 ppm
> 04 Mar 19:31:11         offset: -0.307461       drift: -621.727272727 ppm
> 04 Mar 19:32:11         offset: -0.344903       drift: -622.185430464 ppm
> 04 Mar 19:33:11         offset: -0.382345       drift: -622.491712707 ppm
> 04 Mar 19:34:11         offset: -0.419794       drift: -622.727488152 ppm
> 04 Mar 19:35:11         offset: -0.457239       drift: -622.89626556 ppm


Yea, so from this and the settled ntpdc -c kerninfo data before, we can
see that the drift is further out then the 500ppm NTP can handle.

So with that at least confirmed, we can focus back on to the fast-pit
tsc calibration code.

Ingo, Thomas: I'm missing a bit of the context to that patch, other then
just speeding up boot times, was there other rational for moving away
from the ACPI PM timer based calibration?

Could we maybe add a quick test that the pit reads actually take the
assumed 2us max? Doing this maybe via the HPET/ACPI PM?

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/