linux-kernel - Re: [PATCH] hpet: factor timer allocate from open

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: <1f1b08da1003011259yed7c61bvb18071eb8e465bca@mail.gmail.com>
Date:	Mon, 1 Mar 2010 12:59:06 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Magnus Lynch <maglyx@...il.com>
Cc:	Clemens Ladisch <clemens@...isch.de>,
	"Venkatesh Pallipadi (Venki)" <venkatesh.pallipadi@...el.com>,
	Vojtech Pavlik <vojtech@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hpet: factor timer allocate from open

On Mon, Mar 1, 2010 at 12:24 PM, Magnus Lynch <maglyx@...il.com> wrote:
> Clemens Ladisch wrote:
>> A ioctl to read the main counter would just duplicate clock_gettime(),
>> but I cannot see any benefit over that.
>
> In fact for my situation I attempted using clock_gettime first and found it
> unsuitable. Specifically, my case is finding a substitute for RDTSC as a
> constant-rate counter for use in correcting real-time clock drift. This is for
> a CPU without constant TSC, as many are; and I was patching DJ Bernstein's
> excellent program clockspeed to be workable in such a case.
>
> Calculating the real time tick rate of clock_gettime using CLOCK_MONOTONIC
> suspiciously yielded a rate almost exactly 1GHz, which seemed to imply some
> feedback relative to real time was happening and thus wouldn't be reliably
> constant rate in the face of slewing the clock. Whatever the reason, in fact
> it wasn't and trying to depend on it as a constant rate timer while using
> adjtime quickly led to inaccuracies... Which led me to HPET as a solution,
> which worked swimmingly.
>
> I do now see there's another clockid, CLOCK_MONOTONIC_RAW, whose name implies
> it might work for me. I'll try it and see.

Yes, CLOCK_MONOTONIC_RAW was added specifically to create a hardware
agnostic interface that provided a 1:1 ratio to the hardware cycle
counter used by the timekeeping core. No NTP corrections or slewing
are applied and it isn't affected by settimeofday calls.

Let me know if you run into any trouble with it.
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/