From owner-freebsd-arch Fri Oct 26 14:18: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8401A37B401; Fri, 26 Oct 2001 14:17:55 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id f9QLHGM08188; Fri, 26 Oct 2001 23:17:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. In-Reply-To: Your message of "Fri, 26 Oct 2001 14:08:49 PDT." <200110262108.f9QL8n238592@apollo.backplane.com> Date: Fri, 26 Oct 2001 23:17:16 +0200 Message-ID: <8186.1004131036@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200110262108.f9QL8n238592@apollo.backplane.com>, Matthew Dillon wri tes: >:> There can be no doubt that the best timestamp representation is >:> pure binary, originating at the second, and that is how my proposal >:> is constructed: >:> >:> <-- 32bit --><-- 32bit --> . <-- 32bit --><-- 32bit --> >:> 1 2 3 4 >: >:IOW, a fixed-point number. This is definitely the optimal solution presented >:so far for the in-kernel time keeping, IMO. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > Not. Not exactly, anyway. A base-2 fractional representation will > introduce serious rounding errors for anyone doing any sort of arithmatic. > For example, the representation of a nanosecond is 2^64/1E9 = > 18,446,744,073.7. If you add two 1 nanosecond values together, you don't > get 2 ns. I think I see your anti-phk reflex kick in here, but let me answer anyway: Any physicist or engineer knows something about "significant digits" and that applies here as well. You don't add two nanoseconds together. If your numbers are in that range, you add some multiple of 1/2^64 s together, and the rounding errors will be totally insignificant. Nothing in your computer happens in multiple of nano-seconds, it happens in multiple of clock cycles. Modern clockcycles hate nanoseconds: 1400 MHz = .714285... nsec > A base-10 fractional representation (1.0E+19) rather then 2^64 is > almost certainly going to be a better all-around representation. > In that case 1nS winds up being 1E19/1E9 = 1E10. 1 picosecond winds > up being 1E7, and so forth. There is only one problems: it will make everything slower because computers are binary: any conversion to get seconds will cost you a (long) division, which is still 30 times more expensive than a multiplication. Computers are binary and work best in binary. Time is a floating point unit (as far as physics have been able to make out, it could be rational though) -- 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