From owner-freebsd-arch Wed Oct 31 13: 5:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by hub.freebsd.org (Postfix) with ESMTP id 48F9B37B406 for ; Wed, 31 Oct 2001 13:05:16 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id QAA16756; Wed, 31 Oct 2001 16:04:57 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110312104.QAA16756@wellington.cnchost.com> To: Poul-Henning Kamp Cc: Peter Jeremy , Peter Wemm , arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. In-reply-to: Your message of "Wed, 31 Oct 2001 21:18:55 +0100." <75868.1004559535@critter.freebsd.dk> Date: Wed, 31 Oct 2001 13:04:55 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Using double in the kernel is not needed. Not needed because...? Actually double arithmetic is even faster! 45ns for divide on the same machine where I get 130ns for long long divide. In the program I posted change all long long to double and fix up io conversion. Changing it to long double yields 62ns; still faster than long long. I bet your 128 bit fixed point will be much worse. > 10^-9 is not enough internal resolution for an NTP compliant > timekeeping implementation. We currently use 10E-9/2^32. Which your average machine isn't. PCs and even suns or sgis and whatnot have crystals with lousy staibility as you well know. > There is _no_ benefit to use a metric unit internally in > the kernel, in fact, there is only extra overhead whenever > you add together or subtract two timestamps, (which we do > everytime we (re)schedule a task on a cpu). Well you don't keep a pair like in timeval or timespec. It is a long long where the unit of count is 1 ns so there is no extra overhead (but you are better off using a long double!). Also, shouldn't you be using time relative to boot time for scheduling? > > - very few applications require resolution less than 1ns. > ... yet. (Submitted to "Famous last words" for consideration). This is not the same case as having insufficient number of bits in an address or 640Kbytes being good enough. I am sure there will be more and more applications the % won't increase. 128 bit is enough but not necessary for most userland apps. > Here we have the primary need of the process statistics > which need to figure out how long time each process sat > on the CPU, and the devinfo stuff which calculates device > statistics. These two together are the overwhelming > users of timestamps in the kernel. This should be using bootime specific time type, which doesn't need multi century range but finer resolution. > They both need to find delta-T's. They get a timestamp, > wait some time, get another one, subtract them. For this > the timespec/timeval mess sux. Agreed. > We can argue what resolution we need for this, but I think > that with 2GHz CPU's announced, 1 nanosecond is not enough > for very long time. We want to be able to account (and > profile!) down to the cpu-clock. 32bit fractions of second > gives us 4.mumble GHz, that is not enough for long enough. I have no problem in using a finer clock here; I just don't think it should be the same as a generic time type. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message