From owner-freebsd-hackers Mon Aug 17 19:28:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA14233 for freebsd-hackers-outgoing; Mon, 17 Aug 1998 19:28:13 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com ([203.8.14.118]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA14213 for ; Mon, 17 Aug 1998 19:28:09 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.8) with ESMTP id SAA00292; Mon, 17 Aug 1998 18:25:02 GMT (envelope-from mike@dingo.cdrom.com) Message-Id: <199808171825.SAA00292@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: joerg@krdl.org.sg (Joerg Micheel), ac199@hwcn.org, grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t In-reply-to: Your message of "Mon, 17 Aug 1998 06:02:42 GMT." <199808170602.XAA20899@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Aug 1998 18:25:02 +0000 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What bothers much more is resolution. Many things of interest now happen > > in fractions of milliseconds. Look at the clock frequency of computers > > or the clock of networks (SONET, etc). Nanosecond granularity is a must, > > if you'd like to accurately describe an interval it takes to compute or > > transmit a certain piece of information. Please note that granularity > > does not mean accuracy (it has never been). > > Right. For example, all resoloution better than a second is arrived > at through interpolation, and has been for a long time. SunOS 4 > interpolated to a resoloution of 4uS (based on the time it took to > make a system call vs. the speed of the hardware at the time). Not correct on systems Pentium and above, where the cycle counter is used. It's been a while since I looked at the code, but basically the cycle count is stored each tick and the number of cycles per tick is known, so a rapid calculation can be performed to obtain the offset from the last tick (whose time is known) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message