Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Oct 2001 23:17:16 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Bakul Shah <bakul@bitblocks.com>
Subject:   Re: 64 bit times revisited.. 
Message-ID:  <8186.1004131036@critter.freebsd.dk>
In-Reply-To: Your message of "Fri, 26 Oct 2001 14:08:49 PDT." <200110262108.f9QL8n238592@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8186.1004131036>