Date: Fri, 26 Oct 2001 21:46:51 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bakul Shah <bakul@bitblocks.com> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <6790.1004125611@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 26 Oct 2001 12:15:00 PDT." <200110261914.PAA17908@devonshire.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200110261914.PAA17908@devonshire.cnchost.com>, Bakul Shah writes:
>> Decimal computers lost the race and they ain't coming back. We want
>> arithmetic on binary computers to be fast and simple.
>
>Most everyone uses powers of ten for timing units. Remember,
>millisecond, microsecond, nanosecond, picosecond?! All test
>equipment time in units of 10s not 2s. That is also why CPUs
>have clock rate in multiples of 10^6 Hzs not 2^20. It is
>just being practical even if division by a power of 10 is a
>bit of a pain.
Right. Almost everyone uses powers of their monetary units
as well, yet they use binary numbers to represent them.
The problem is that people tend to think of time as integers
instead of a floating point value.
1 second 500 million nanoseconds should not be represented as
"1 times foo + 500000000 times bar"
it should be represented as
"1.5 times foo"
The lowest level of timekeeping code in the kernel, the timecounters,
need to operate at a level of precision where they can faithfully
represent the frequency of whatever hardware we throw at them.
Since we accumulate tics, usually at a rate of hz, a resolution of
one nanosecond is not enough for frequencies much higher than approx
50 MHz. Our timecounting code already operates with a precision
of 32bit fraction of nanoseconds for this reason.
In order to support timespec, the chosen format is actually:
<--32 bit sec--><--32 bit nsec--><--32bit fractional nsec-->
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
You can then use whatever subset you want for particular purposes,
and not pay an arm and a leg in conversion costs:
2 alone is the same as time_t today
2+3 is enough to convert til timeval/timespec:
tv->tv_sec = ts->f2
tv->tv_usec = ((u_int64_t)ts->f3 * 1000000) >> 32;
ts->tv_sec = ts->f2
ts->tv_nsec = ((u_int64_t)ts->f3 * 1000000000) >> 32;
(no divisions!)
2+3 is identical to NTP timestamps.
1+2 = 64 bit seconds ("time_t_ng")
1+2+3+4 = enough for anything anybody can think of.
--
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?6790.1004125611>