Date: Wed, 31 Oct 2001 21:18:55 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bakul Shah <bakul@bitblocks.com> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <75868.1004559535@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 31 Oct 2001 11:47:28 PST." <200110311947.OAA05182@devonshire.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200110311947.OAA05182@devonshire.cnchost.com>, Bakul Shah writes: >> 1) Fixed point seconds with M bits to the left of the binary >> point and N bits to the right. >> 2) Integral number of (fractional second units). (As used on >> the IBM System 360 and later). > >My vote is for 2), where the fractional unit is 10^-9 seconds >and I called it `nstime64_t'. I don't like fixed point. You >may as well use floating point like long double since most >processors these days have very good floating point >performance but then it won't make the embedded system folks >happy. Using double in the kernel is not needed. 10^-9 is not enough internal resolution for an NTP compliant timekeeping implementation. We currently use 10E-9/2^32. 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). > - very few applications require resolution less than 1ns. ... yet. (Submitted to "Famous last words" for consideration). There are a number of considerations, which build on each other. Lets tackle them bottom up: Timecounter implementation: Needs to be able to tell 1433 MHz from 1500 MHz. This is the difference between .6666 nsec and .692856... nsec. Currently the format used is a 96 bit format: 32bit seconds 32bit nanoseconds 32bit fraction of nanoseconds A lot of special casing code can go away if this becomes a simple binary format instead. Since computers of relevance are 32bit or 64bit the logical widths are 64 (not enough), 96(not enough for enough time) or 128 (enough!). Kernel consumers of time: 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. 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. 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. In other words, we need a fraction of seconds with more than 32 bits. More than 32bits is 64 bits. 53 bits is simply not a good idea on 32 or 64 bit computers... Userland consumers: Generally want timeval or timespec because of various standards brain-damage. So, where does that leave us ? 1. nanoseconds are not enough. 2. We have to use 64bit fractions of seconds unless we want to shift all the time. 3. An internal 64.64 fixed point binary format can be converted to practically any other timeformat and is cheaper to convert and do arithmetic on than any other format. 4. For a couple of years we can make do with a 64bit (32.32) format for process accounting if we want to, but long term it will not hold up. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75868.1004559535>