From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24532 invoked by alias); 13 Nov 2003 22:54:56 -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 24516 invoked from network); 13 Nov 2003 22:54:56 -0000 Received: from unknown (HELO palrel12.hp.com) (156.153.255.237) by sources.redhat.com with SMTP; 13 Nov 2003 22:54:56 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel12.hp.com (Postfix) with ESMTP id C17DD1C01400; Thu, 13 Nov 2003 14:54:55 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id hADMsswU023780; Thu, 13 Nov 2003 14:54:55 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id hADMssFO019734; Thu, 13 Nov 2003 14:54:54 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) id hADMssOI019730; Thu, 13 Nov 2003 14:54:54 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16308.3006.52067.235699@napali.hpl.hp.com> Date: Thu, 13 Nov 2003 22:54:00 -0000 To: Jes Sorensen Cc: Ulrich Drepper , libc-hacker@sources.redhat.com, davidm@hpl.hp.com Subject: Re: ia64 clock_gettime and HP_TIMING In-Reply-To: References: <16306.21333.78785.923547@gargle.gargle.HOWL> <3FB2751B.9010302@redhat.com> <3FB34B5A.2040209@redhat.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2003-11/txt/msg00047.txt.bz2 >>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen said: Ulrich> The HP clocks are extremely useful. They stay. Jes> I am not saying that should go, I am just asking we come up Jes> with a solution that means our binaries return an error rather Jes> return unreliable data. 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? All platforms with drifting cycle-counters have a common (CPU-external) high-precision timer, so shouldn't you be using that instead of returning an error? I didn't get Uli's point about gettimeofday() not being sufficiently accurate, though. True, the current light-weight gettimeofday() does only ITC-based interpolation (and falls back on heavy-weight syscall otherwise), but that still gives rather high precision (sub-microsecond, at least). Moreover, I don't see any reason why the light-weight system call couldn't be extended to support HPET and perhaps SGI's timer (since they never seem to use standardized hardware... ;-/ ). Whether or not the resulting gettimeofday() would be sufficient for HP_TIMING purposes, I don't know. --david