From owner-freebsd-arch Fri Oct 26 14: 8:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B00437B403; Fri, 26 Oct 2001 14:08:50 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9QL8n238592; Fri, 26 Oct 2001 14:08:49 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 14:08:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200110262108.f9QL8n238592@apollo.backplane.com> To: John Baldwin Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, Peter Wemm , Bakul Shah Subject: Re: 64 bit times revisited.. References: 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 :> :> If you look in sys/kern/kern_tc.c you can see how much extra :> gunk that results in, checking for overruns on the middle part and :> whats not. :> :> 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. 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message