Date: Fri, 26 Oct 2001 14:08:49 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Bakul Shah <bakul@bitblocks.com> Subject: Re: 64 bit times revisited.. Message-ID: <200110262108.f9QL8n238592@apollo.backplane.com> References: <XFMail.011026131501.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :> 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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110262108.f9QL8n238592>