From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17213 invoked by alias); 14 Nov 2003 09:46:44 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 17197 invoked from network); 14 Nov 2003 09:46:43 -0000 Received: from unknown (HELO jaguar.mkp.net) (192.139.46.146) by sources.redhat.com with SMTP; 14 Nov 2003 09:46:43 -0000 Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1) id 1AKaNr-0002qq-00; Fri, 14 Nov 2003 04:36:55 -0500 To: davidm@hpl.hp.com Cc: Ulrich Drepper , libc-hacker@sources.redhat.com Subject: Re: ia64 clock_gettime and HP_TIMING References: <16306.21333.78785.923547@gargle.gargle.HOWL> <3FB2751B.9010302@redhat.com> <3FB34B5A.2040209@redhat.com> <16308.3006.52067.235699@napali.hpl.hp.com> From: Jes Sorensen Date: Fri, 14 Nov 2003 09:46:00 -0000 In-Reply-To: <16308.3006.52067.235699@napali.hpl.hp.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00063.txt.bz2 >>>>> "David" == David Mosberger writes: >>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen said: Ulrich> The HP clocks are extremely useful. They stay. Jes> How do you feel about a solution where we add a runtime check Jes> against /proc/sal/itc_drift and handle it appropriately within Jes> the HP_TIMING macros? David> All platforms with drifting cycle-counters have a common David> (CPU-external) high-precision timer, so shouldn't you be using David> that instead of returning an error? Can you point me to some specs for that and I'll take a look at cooking up a patch? David> Moreover, I don't see any reason why the light-weight system David> call couldn't be extended to support HPET and perhaps SGI's David> timer (since they never seem to use standardized David> hardware... ;-/ ). Whether or not the resulting gettimeofday() David> would be sufficient for HP_TIMING purposes, I don't know. I'll see what I can come up with patch wise for something that allows the HP_TIMING to be flagged as available/unavailable runtime as well as supporting the HPET (if I can find info about it somewhere). Should be pretty easy to setup something the first time get_clockfreq() is called. Not knowing enough about HPET, my biggest worry is if we have to open up an extra file descriptor for a permanent mmap of it. Cheers, Jes